Voyage 200 Upgrades

So it's been just over a year. I had misplaced my V200 for about 2 months while not being to work on it. Charged up the batteries and it still works flawlessly. I've been very busy at my place of work and have been moving foward with some lighting projects which I'll put up here later. I've not have any crashes outside of the ones in the test I've mentioned and everything is still stable @ ~27.5-27.6 MHz. I'll be working on the back lighting in the near future and also I've identified the LDO for the LCD drivers. I have not though, been able to identify which LDO models they are.

Somewhere someone knows something I do not. It was more than a decade ago that overclocking these calculators was common knowledge. Half of the sources have disappeared over time and the other half tell you nothing more than the instructions and the maximum speed the calculator will run at and why. The 6 overclocks I've done support this information, i.e. 22 pF w/ 1.43 kOhm resistor being the fastest OC and sometime unstable with stock SRAM, but I'm still at a loss to quantify the circuity of the clock generator which is why I wanted to do this mod in particular.

• This isn't a simple, bare bones RC oscillator
• The frequency of the RC pair is slower than the output clock for the MCU/CPU
  
  • I'm still scratching my head over this detail
  • Maybe its the capacitive reactance of my probe?
    • But its a 6.5 pF tip. With the ground lead, it's higher capacitance, no?
    • The frequency was the same with just a ground spring though
• This isn't a phase-shift RC oscillator
• The resistor is in parallel to the ASIC and the capacitor
• After a few hours of looking over schematics, I cannot find a reasonable account for the fundamental design of this clock generator
• Plotting the data I have, albeit 6 samples with frequencies sensitive to temperature, shows that a natural log function fits the data with the x-axis being expected frequency and y-axis being the resulting frequency
• Once the oscillator's behavior can be characterized, a function can be generated to plot predictable frequencies.

Photo of the V200 with the resistor and capacitor removed

Maybe I should poke around a bit more with my scope. I got similar frequencies on more than one other pins on the ASIC. TICT's documents on TI's 68K calculators is nice, but it's hardware is written from a software perspective and gives little insight into the functionality of the hardware. Anyhow, I'd like to make a correction of a spec I overlooked: the NOR FLASH can run at 10 MHz, not the previously stated 5 MHz.

SRAM Limit

This plainly leaves the SRAM as the limiting hardware if the MC68K MCU can safely be run at faster speeds. based on the numbers I saw, I'd estimate that the ASIC would have to produce a ~60 MHz clock for the MC68K in order to clock the NOR FLASH that high. Running at 16 MHz chip at 3.75x its rated speed. However, with the SRAM having timings pushed right up to it's minimum spec, I'd have to upgrade it once more. Something more along the lines of Alliance's AS7C31024B-20TCN seems to be necessary and we're stating to see some power hungry components come into play.

Using the limited dataset of 4 OC's with the 4 caps, a logistical regression suggests that a 30 MHz speed would require a 1/RC frequency of ~80 MHz:

Methinks though that this isn't true based on the limited dataset...

LCD Issues

The LCD screen already dims a touch when the CPU is fully engaged. There are 2 SOT-223-3 IC's on the PCB labeled "DRN.3" that are right next to the ASIC that appear to be 3.3 V LDOs and you can see one of them in that photo above, U14. There is another, though, right next to the battery contacts labeled "KFP.3" that also appears to be a 3.3V LDO. LDOs are great for low power, low noise uses, but their efficiency tanks when current draw becomes too much higher.

The screen also gets very dark after soldering around the area indicating some contrast control setup by either of these LDOs methinks. I need a better DMM to make some measurements. I do know that the quad op amp, U15, is applying the LCD bias with voltages up to ~14 V and after soldering the new SRAM, particularly U7, the LCD was also fairly dark for a spell.

I have some LCD polarizer around and I'll be swapping that out to see if I can improve it's contrast ratio before digging into the circuitry. I do have one other sample I wish to purchase to see if it'd help too.

Anyhow, this calculator's functionality is currently more significant than my desire to poke at it with an oscilloscope and DMM so back together it goes.

So, the results are different than expected, but that is just fine. I'm running my V200 at 2x the speed it came from TI. For those who are TL:DR with my logs, you need a 1.21 kOhm resistor and an 18 pF capacitor. I never ran the MD5 checksums as I didn't see anything that presented as instability and I had a continuity problem in a wire from the battery pack that I couldn't be bothered to fix and taking that extra step was too tedious. That at sending a new OS file took about 3.5 min and I had to repeat this test at least once on each over clock after waiting for everything to cool down because even the contrast of the screen was affected by the hot air rework. Results posted after the break.

Okay, so in the course of benchmarking I quickly began to further understand the timings a bit better for the SRAM. The pulses for CE and WE are the crucial ones that are the determining factors for read and write time in this case and I only recorded these values for the 2 highest overclocks. In order of slowest to fastest, here are the results of today's tests:

1.43 kOhm & 51 pF - Stock

• 12.7 MHz RC clock @ 15.2 dB
• 13.6MHz MK68K clock
• NOR ROM Access speed: 1.8 MHz

1.43 kOhm HQ & 33 pF - ~30% OC

• 16.55 MHz RC clock @ 15.6 dB
• 18 MHz MC68K clock
• NOR ROM Access speed: 2.25 MHz

1.43 kOhm HQ & 24 pF - ~55% OC (forgot to grab screen shots)

• 19.4 MHz RC clock @ -- dB
• 21.46 MHz MC68K clock
• NOR ROM Access speed: 2.65 MHz

1.43 kOhm HQ & 18 pF - ~80 OC

• 22.1 MHz RC clock @ 13.6 dB
• 24.87 MHz MC68K clock
• NOR ROM Access speed: 3.1 MHz
• WE time: 38 ns - spec is >35
• CE time: 57 ns - spec is >45

At this point its apparent that the rise and fall times are becoming a bit lengthy relative to the periods. Just to see what would happen, I opted to drop in the 1.21 kOhm resistor of similar spec to see what effect it would have. As it would speed up the RC oscillator, I dropped back to 24 pF...

1.21 kOhm HQ & 24 pF - ~75% OC

• 21.6 MHz RC clock @ 13.6 dB
• 23.84 MHz MC68K clock

So, for about a 4% loss in speed, I gained ~5% faster rise and fall times. Rounding error could attribute for the difference since the numbers computer were of the screen values, not the sampled points with how Rigol doesn't their math.

1.21 kOhm HQ & 18 pF - ~100% OC

• 24.7 RC clock @ 13.6 dB
• 27.55 MHz MC68K clock
• NOR ROM Access speed: 3.45 MHz
• WE time: 34.4 ns - spec is >35
• CE time: 51.6 ns - spec is >45

Tonight's notes:

• The resistor directly affects the rise/fall times of the MCU/CPU clock
• NOR Flash still has room to be "overclocked" though the datasheet implicitly specifies a 5 MHz speed.
• SRAM, even the faster stuff I put in, is technically at it's limit for the overclock.
• Output frequencies do not align with a simple account of parasitic capacitance addition. In the morning I'll plot the data and see what's happening if I can.
• The only game I crashed was SD II, but it was in the same manner both times and given that I've played it before, this came across as a software bug, not a result of the overclock.
• I timed link transfer speeds by nature of sending the OS over. Every results except for stock and the fastest were 3 min and 25 seconds. Stock was 3 min, 40 sec, and 100% OC was 3 min, 50 sec.
  • Since the back half of my TI-89 is soldered to my V200 for power, I could not test calculator-to-calculator speeds.
• Especially after dropping the resistor's value, the screen of the calculator dimmed its contrast a noticeable amount when the CPU was engaged. This is common in low battery situations and it seems that the LDOs next to the ASIC are partly responsible for powering the LCD drivers.
  • This and temperature sensitive contrast is something I wish to investigate and minimize if possible.

Preliminary pre-testing notes:

• The NOR Flash LSB address bit and deduced a ~1.8 MHz clock speed. The chip is rated for 5 MHz tops if memory serves. If the clock speed is linked to then I see a ~2.77x top speed from the overclock
  • Thus ~37.8 MHz before FLASH reads/writes becomes unstable
  • SRAM possible max of 28-30 MHz may become the limit
    • Depending on what errors occur and when, a switchable overclock may be in order
• Link signal is a bit strange and unless errors are thrown, I'm not going to investigate it further. It's a standard, kinda dirty 3.3V signal level shifted to 5V ptp, but with the intentional capacitance added to the level shifting the signal is distorted making it difficult to discern a 1 from a 0
  
  • More details here: https://www.ocf.berkeley.edu/~pad/faq/xfer.html#5
  • My ignorance in logic analysis will impede the results of overclocking if I dive into figuring out the protocol explicitly if no errors are generated.
• The duty cycle of the CPU clock is 55% high, 45% low
  • There is a glitch in the rise of the clock signal for the CPU that happens in 7074 out of 65000 waveforms, ~10.88%, though it is between a 2% and a 3%

• If the threshold is 3% of greater, all waveforms pass.
• This type of information will be useful for comparing signal quality of the output clocks if instability is seen, though on a lower sample population
• The 45 ns SRAM chips are performing without error and will be used permanently as they consume less power
• The 1.43 kOhm resistor is swapped out with one that has known tolerances
• Standard 63/37 solder paste will be used and pads will be cleaned and paste reapplied between each capacitor swap.
• Previous rise and fall times and plots were made without a ground spring on the scope probe. Errors introduced have now been accounted for since I have ground springs despite Amazon's inability to do arithmetic.
  • The fall time of the RC oscillator of ~44.4 ns remains constant
  • The rise time of ~28.9 ns is now reporting as 34.4 ns
  • A 652 mV ptp triangle wave is observed vs the 940 mV ptp.
  • FFT still reported -12.8 dB at native frequency

Photos and results will be posted within the next day or so as long as time permits

The new RAM is in place and the V200 is operating just fine; no reason why it shouldn't. I'm not worried so much about the viability of the RAM, though this removed one more variable to go wrong with the overclock. That said, there aren't a whole lot of tools to testing the hardware of TI's 68K calculators. From the limited programming in TIGCC that I've done, there are a few types of tests that will 'stress' the different components of the hardware: RAM, CPU, FLASH. As such, I've come up with a rudimentary list of tests.Before I get there, I need to measure a few other clocks: input clock on the NOR FLASH, clock for the serial data link. I do not know if these clocks are proportional to the RC oscillator or the MC68K system oscillator. If they are, its possible that overclocking can break their functionality. Anyhow, the tests will be conducted in the following order:

1. Boot from reset
2. Plot sin (x) and cos (x) with zoom fit function
3. Run tibench and compare against oscilloscope
4. Run an md5sum on a file, send to calculator, copy back and run md5sum again
   • Repeat for an Archived file
   • Repeat for a FlashApp
5. Archive and unarchive a 64 KiB file until a garbage collection is forced twice
6. Test execution of grayscale programs using the FAT engine
7. Test execution of Space Dementia II which is a full 3D engine
8. Test display of 8-level grayscale images with PicView
9. Test file compression utility
10. Load an fresh OS to the calculator using TI-Connect and a SilverLink cable

After fighting with Amazon for not knowing how to count to 10 whilst stopping at 1, seriously, I now have some ground springs for my low capacitance probe that I'm using for measurements. It is only 100x, not 10x, but for what I do, I don't mostly need a 10x probe. Anyhow, now that these are in, I have the tools for executing the upgrades.

That, and I have the series of capacitors and resistors I ordered. However, due to car work since I'm my own mechanic and waiting for the arrival of those parts along with DMV drudgery, it may be a week or so before I have initial overclock results. I'm eager to see what assumptions are true, or more importantly false, and lead to some finite data.

I have an ultrasonic cleaner that I need to fix as it blew a fuse and a transistor for its LEDs when I connected what looked like ground to the ground clip on the probe. Looks like its polarities are flipped. DMM is going up next to to figure out how the hell this thing is wired. Either way, it's taking up space on the counter I need for calculator hacking and I don't have as much free time as I'd like right now.

On my TI-89, one of the battery contacts on the PCB was heavily corroded and it took a good deal of time and heat to reflow solder to make a new pad. I did this to the V200 as a preventative measure too, but I guess I heated up the nearby fuse to where it blew. So I used the one from my '89. That then blew today as well...

The numbers I've run didn't match the numbers and results others have posted so I needed to measure things a bit more closely. While probing pin 6 of my V200's MC68K, the shut off as I just mentioned about. As far as I can tell it's a 500 mA, 1/2 Amp, 6mm x 2.5 mm fuse. I've ordered 3 from mouser and am using a wire to short the fuse's terminnal in the interim...

The V200 is known to run at "12 MHz" and you can find this quoted in numerous places. The RC oscillator produces a frequency of ~12.7 MHz at ~13 dB as I previously measured. And, since I never measured the clock going into the MC68K, well, I though I should do that. Guess what I got? How about 13.7 MHz, which is nearly bang on with 1 / RC for 1.43 kOhm ohm and 51 pF.

Here is what that square wave looks like on pin 6 of the MC68K:

Ignore the hardware counter as the CPU is idling and the signal also looks horrible simply because I somehow missed getting ground springs for this new probe.

Since I cannot find a full datasheet on the MC68SEC000PB16, I don't know how the internals of the clock generator work so I'm somewhat confused as to how you get a 13.7 MHz signal from a 12.7 MHz oscillator.

Also, there is a program I forgot about, tibench, and it's accuracy is claimed to be pretty good, but I do not know if that has been verified by looking at the hardware with a scope. However, running the benchmark gives the output of ~13.59 MHz.

So in other words, software and hardware are close enough to know that I'm not missing anything about the calculators running faster.

With that said, I took a closer look at the RC oscillator's waveform.

Small note is that it idles at 3.3 V and then the pin is pulled low to enable the clock for anywhere from 4 cycles to 100% DC. The V200 clock is ~720 mV pp whereas the TI-89's is ~940 mV pp, but both with similar minimums of ~1.1 V. Running the numbers for the observed ~28.9 ns rise time and ~44.4 ns fall time results in values for the resistor of that RC oscillator that do not match the 1.43 kOhm value stated and measured.

In fact, they are much closer to 3.3 kOhm and 4 kOhm respectively and their difference is ~670 ohm. Effectively we're charging through 1.87 kOhm + 1.43 kOhm and then discharging through 1.87 kOhm + 670 ohm + 1.43 kOhm.

Why am I nit picking? Well, with the V200 clock running a lower peak to peak voltage and the rise and fall times are slower than what the apparent RC pair should generate so if the C9's value is decreased, the rise and fall times obviously lower, but that also means the peak to peak voltage begins to drop as well. Now we can guess how much. Just for some extra leeway, I'm going to adjust R1's value in order to try to bring the 'stock' voltage up to that of the TI-89 and that puts it at ~732 ohms ideally, though 750 ohms is what is available. To be safe though, I'm also choosing 1.02 kOhm and 1.21 kOhm resistors in case R1's values affects the clock value dramatically because something might be wrong with the assumptions. This is indicative to even if I ignore 4 pf of parasitic capacitance, even adding half of 670 ohms drops the RC oscillator frequency to 11.1 MHz, well below 12.7 MHz. Raising the peak to peak voltage level will also increase signal quality if this can be achieved.

Things I'm considering with the overclocking:

• Anything faster than 16 MHz is considered an OC of the MC68K
• Anything faster than a 70 ns period is considered an OS of the *old* SRAM
  • Previous individuals have been able to reach ~22 MHz w/o a RAM upgrade which is a 45 ns period or about a 22 ns pulse.
    • 25 ns is the lowest max time spec of the CE and OE pins
    • 30 ns is the minimum time spec for data setup to a write completion
• Anything faster than a 45 ns period is considered an OC of the *new* SRAM
  • Assuming the MC68K can keep up with the OC and the SRAM is the limit, the following may be true
    • 16 ns is proportional to the 18 ns spec for CE and OE pins as 22 ns is to 25 ns
    • 18 ns is proportional to the 25 ns spec for data setup to a write completion as 22 ns is to 30 ns.
    • It is possible the max frequency for an OC to be 28-30 MHz though
• Due to a 22 pF creating a 1.8x-2x not ~2.3x speed up and an 8 pF cap causing a 2x-3x not ~6.4x speed up, there is something else causing the clock generator to not function properly.
  
  • If the ASIC has 4 pF of parasitic capacitance, the previous 2 cap values would net a 2.1x and 4.6x speedup.
  • If my measurements of the caps is wrong and they are 47 pF instead of 51 pF, stray capacitance doubles to 8 pF and brings those speedups to 1.8x and 3.4x which matches previous observations better.
  • I need a decent LC and ESR meter...

Anyhow, as a result I'm re-doing my capacitor selection. Also, since quarters are of no object, i.e. since the difference between $0.14 capacitors and $1 capacitors is less than lunch money, I'm going to splurge even more though I'm going to remain specific. The RC oscillator source had a frequency output about 2.4 dB worse on the V200 than the TI-89. I noted in the mouser search parameters a "High Q" MLCC selection. A higher Q in filtering means that the quality of a resonant circuit is increased and thus I hope they can improve that signal quality regardless of the OC. Finally, with the resistor spread and the near guarantee of being able to get 2x performance at 22 pF w/o an SRAM upgrade, I'm choosing the following 4 capacitor values: 16 pF, 18 pF, 24 pF, 33 pF

Anyhow, the results of the time I've spent on this today are the following

• Resistors:
  
  • 1.21 kOhm, 0.1%, 10 PPM / ˚C - RN73C1J1K21BTG
  • 1.02 kOhm, 0.1%, 10 PPM / ˚C - RN73C1J1K02BTG
  • 750 Ohms, 0.1%, 10 PPM / ˚C - RN73C1J750RBTDF
• Capacitors:
  
  • 33 pF, 2%, C0G - 251R14S330GV4T - 21.2-40.4 MHz estimated clocks
  • 24 pF, 2%, C0G - 251R14S240GV4T - 29.1-55.6 MHz estimated clocks
  • 18 pF, 2%, C0G - 251R14S180GV4T or GQM1885C1H180GB01D - 38.9-74.1 MHz estimated clocks
  • 16 pF, 2%, C0G - 251R14S160GV4T - 43.7-83.3 MHz estimated clocks

Frequencies by Resistor, Low = +8 pF parasitic, +4 pF parasitic, High = +0 pF parasitic:

Frequency Stepping, Low = +8 pF parasitic, +4 pF parasitic, High = 0 pF parasitic:

For some reason the 47 pF value for the caps is sitting in my mind. Either after 'calibration' the LC meter is so far off that it read both my TI-89's and my V200's caps 51 pf, both ~8% high, or both of them are within their 10% tolerance and reading 8% high, or the LC meter is right. I have a bunch of uF caps, but no spare pF caps so I'll defer to Occam's razor and say that both caps are 51 pf.

With that said, I know the proposed speeds my HW1 TI-89 and my V200 are supposed to be running at: 10 MHz and 12 MHz respectively. I was happy to see sleeping occurring on both calculators, but experience has shown that this was expected. I loaded up a quick looping "benchmark" to be able to pull the clock on full time and went at it with my scope. First up, my TI-89:

-12.8 dB for the frequency output in case anyone was wondering. This was computed with a Hanning windowing.

Next up is my V200:

About a 2.4 dB loss in the signal quality which is perceptable by the fuzziness of the sample in the first screen shot compared to the 89's.

Anyhow, since I've not worked with RC oscillators yet, a quick google search revealed the relatively simple formula of 1/(RC) to determine the frequency, though that gives rise to a small problem.

The RC pair on the TI-89 HW 1 is a 1.12 Kohm resistor and a 51 pF cap. This yeilds a frequency of ~17.5 MHz. Ummm, yeah, that isn't anywhere near 10.5 MHz so there must be some stray capacitance in the board or silicon, et al. Well, in order to bring the frequency down to ~10.5 MHz, we have to add in a series capacitance of ~34 pF and that's no small chunk of the original capacitor. More on this after we move over to the V200, the project child.

The V200's RC pair is made of a 1.43 Kohm resistor and a similar, though one size smaller, 51 pF cap. Plugging these in we get an oscillating frequency of ~13.7 MHz. Not bad, but still a bit off. Given that there is 1 hardware generation and about 5 years between them, it's good to see that this stray capacitance now works out to ~4 pF, an order of magnitude better.

Anyhow, with that said, if I were to OC my TI-89, I'd need much larger jumps in order to create the same performance. And at the same time, the stray 4 pF of capacitance in the V200 wasn't taken into account on my original estimated frequencies:

• 33 pf = ~18.9 MHz, -11%
• 27 pf = ~22.6 MHz, -13%
• 24 pf = ~25 MHz, -15%
• 20 pf = ~29.1 MHz, -17%
• 16 pf = ~35 MHz, -20%

Well, this one is a bit of a gamble. Unlike SRAM, it seems like there hasn't been a need in the NOR Flash market for any sizable increases. The 4 MB LH28F320BFHE-PBTLZ2, organized as 2 MBit x 16, has a read cycle time of 80 ns and a top operational speed of 5 MHz. The fastest replacement I can find is made by Spansion.The S29JL032J60TFI020 and has a read cycle time of 60 ns but also a top operational speed of 5 MHz. So, same signaling rate and lower latency? Granted it's 25% though I was disappointed to find this out.

"But it's Flash! You don't need it to be faster."

Yeah, well the way the TI calculators are setup your effective harddrive is the "ROM". Execution cannot happen from ROM but if you have a lot of programs, albeit games, or TI's Flash Apps, you drop from reading and writing at 12 MHz to 5 MHz and that has always been noticeable. That said, 60 ns latency to 80 ns latency might increase the bandwidth as long as the OS isn't hardcoded with delays for accessing the ROM.

With that said, some other complaints or problems with overclocking is boot errors so decreasing the latency spread of the Flash and SRAM wouldn't be a bad thing. I do wish it wouldn't cost $2.85 for such a meager upgrade. I does look like it'll consume between 33% and 60% less current and it's standby current is an order of magnitude better.

That all said, I'm not sure if it'll work. The Spansion chip allows reading while writing data and other configurable options. Honestly, without knowing all that is happening I won't know if this chip is compatible.

Lastly, I check the pinout. Probably should've done this first as they differ sigificantly. Too much so I'm going to forgo 'upgrading' this IC.

Yeah, I wrote these two in reverse order because one idea is easy to follow through one, even though it was not the original cause behind all of this. Despite it's slow AMS, the V200 is very dependable and I use it from unit conversions and calculations all of the way to the occasional derivative or integral. That said, I spend a lot of my free time awake in the not so bright time of day. Though night is more peaceful, it is considerably darker. As such, I've wanted to see how difficult it would be to make a custom backlight for my V200 so I took it apart.

As try as I might, the SOT-223 LDO that powers the whole calculator is one that I cannot identify. As such, I have to be careful with the extra power I'm drawing and make sure I don't affect the other IC's on the board. Because I couldn't spec it and from more than a decade of use, I know how this calculator responds when it is browning out. Adding an additional load to the LDO will greatly decrease it's efficiency and drain the 4 AAA batteries oh so much faster.

Now, as much as I'd like to talk about the backlight setup, that modification runs a much greater risk of damaging that calculator that will force me to buy a new one due to breaking one of 2 ribbon cables or snapping the glass of the LCD. I've not begun planning for this process yet, so I'll touch on the more immediate current draw problem I have: the overclocking. Reason stands that the SRAM speed is the limit to the overclock. Despite the additional current draw of the ASIC and MCU from the OC, the SRAM needs to be faster, which could mean more current. As such, I've established a limit of such that the 20 mA max current draw for the current SRAM chips I plan on upgrading is something I cannot overshoot, over better yet, improve upon.

Have a look about a third of the way through for the original RAM details and part number

After plugging in the details, I have 2 options for upgrades:

A "16 mA", 45 ns variant of the original, i.e. CY62128EV30LL-45ZXI

or a "2.5 mA", 45 ns ISSI chip, the IS62WV1288DBLL45TLI

Their pinouts and high/low enable pins are the same. Looking through the datasheets, the Cypress SRAM has an operating current of 11-16 mA and the ISSI one is 8-15 mA. The supply currents top out at 1.3-2 mA and 2.5-3 mA respectively. And finally the standby currents both top out at 4 uA. Both of these chips beat out the original with ratings of 20 mA for operating current and 12 uA for standby.

There is spec I'm happy to have noted as well, input and output capacitance. The original Cypress chip is rated for 6 pF and 8 pF respectively. The ISSI chip matches this spec, but the newer Cypress chip does not with a rating of 10 pF for both. When looking at the timing table for both the ISSI is a bit better in this regard as well, which makes complete sense.

Yeah, it's a bit of effort to find the right RAM when many have OC'd their calculator without upgrading it, but I rather have this upgrade be reliable and just as dependable. That and if I choose not to OC the calculator, the already 3-6 month lifetime of 4 NiMH AAA's should grow a bit more, no?