Hi! I'm one of the contributors to the third-party C toolchain for the CE. I was working on a patch for the Python app a while back before giving up because there was so little RAM that it couldn't hold all the functions for the main processor's graphics API, even though the Python code was all just like one line per function since it was literally doing all the work on the other processor. As a software guy, I hadn't really messed around with test points much, beyond dumping the ARM's ROM, so it's good that someone's documented some of those. I've previously worked out what most of the escape sequences the calculator uses do - of the 7 they've implemented, 2 are entirely custom, and the remaining 5 use the same final character as an ANSI sequence that does about the same thing, but annoyingly none of them are actually standard-compliant. For example, ESC [ m is Set Graphics Rendition, which sets the text color, but it uses entirely different numbers for each color than regular terminals do. As you speculated, there's also an SPI connection between the two processors, which is used when transferring the firmware, programs, TI-OS lists, certain graphics data, etc. I still haven't entirely figured out how that works, either in terms of protocol, which test points it's using, or what system calls it uses. As for why the keyboard is doing that - the OS has a complicated system of scan codes and key codes and tokens that it uses, none of which are ASCII, and the keyboard inputs get translated into key codes. The Python app listens for key codes using the OS's functions, then translates them into ASCII strings, and probably wasn't designed with an external keyboard in mind, which is why it's so jank. eZ80acclaim! is the name of one of Zilog's single chip computers, while the CE uses a different custom ASIC that implements the same eZ80 ISA. And yeah, a lot of the code has been completely untouched for decades - when writing assembly code for it I still find myself primarily referencing SDK documentation for the TI-83 that's nearly as old as I am. There are also several other TI calculators that have worse names than this one, somehow - there's the TI-83 Premium CE Edition Python, which is exactly the same thing but in French but cheaper and with slightly more software features, and the TI-82 Advanced Edition Python, which is exactly the same thing but in the old style of case and with a different OS.
You’re insane, in the best possible way. I laughed, I cried, I learned. But I probably won’t open up my TI 84 CE Python since I learned all I need to know. Aside: I learned to program in BASIC on the RadShack Model 100, and I too would much rather play with Python on one of my Pis.
I don't know that I'd call this solution janky. They've effectively grafted in an embedded Python subsystem with minimal changes needed to be made to the existing calculator design. Doing so, they don't need to recompile Python to run on the Z80 and none of the calculations running on Python use the Z80. This is a pretty elegant way to introduce a modern programming environment while keeping the rest of the calculator largely unaltered. Contrast this with the WinCE update added to HP Prime and the overhead is almost nothing. What's perhaps more interesting is because the Python module is just a serial connection, you could replace it with anything else which uses a serial connection, not just limiting yourself to Python.
also, it would be pretty great to replace the little chip with literally anything else to add additional functionality, as the calculator is basically just a terminal
This is the weird kind of tech stuff I love from this channel. This, general conversation and talking through a discovery in real time, Bud, singing, more Bud, a can of beer near the end of the video, soldering, and singing. Oh, and just general conversation and talking through a discovery in real time. BTW, don't forget Bud.
Great video! The first escape sequence that you’ve got on the oscilloscope “1B 5B 46” was the equivalent of pressing the END key on the keyboard, to move the cursor to the end of the line, followed by pressing the ENTER key (the 0D at the end).
24:30 The part you want is an "Analog Switch" like a 74LVC1G315, they're super useful for making mods like this. You can connect the 'gate' input of the switch to the FTDI chip's 'TX activity' pin (normally used for enabling a RS485 output driver and/or blinking the TX activity LED), and just otherwise have the appropriate pullup/pulldown resistor to keep the line connected normally whenever the FTDI is not actively sending a byte (or indeed, when it's disconnected). (I've used that exact chip for modding in one of those bluetooth wireless serial modules into a USB serial device, worked like a charm!)
First time watching this channel, thought it was going to be a much more rudimentary video. Did not expect a sufficiently advanced level of EE knowledge. Very interesting.
Great video! It's great to see that our beloved Z80 is not dead! I would guess they chose UART protocol because it is asynchronous, which corresponds to the nature of the transfers happening: the Z80 sends data to the ARM core, this one will process them and send the response later. With SPI on the other hand, transfers are all synchronous and initiated by the master (Z80) but the Z80 doesn't know when the ARM core has finished processing the data. In practice they could have added a ready line between both cores with a GPIO, but from what I see, they didn't want to bother with the software. I would have loved to see the how the data were transferred with a graphical/plotting Python example.
The HP Prime graphing calculator, like the Numworks, also runs Python natively. It uses a beast of processor though, an ARM Cortex A7 @528 Mhz, with 256 Mb of RAM and 512 Mb of flash.
In theory you could replace the slow Python microprocessor with a 100x faster Raspberry Pi. And also watch Linux boot process running inside the Python mode!
I can see not wanting to rewrite all their Z80 stuff to work on an ARM. It works and porting it would probably only add bugs. Wonder why they don't do like HP did on the HP49/HP50 and run an emulator of their older CPU. For those not in the know, the HP 48 ran a (very slow) custom CPU called a Saturn: en.wikipedia.org/wiki/HP_Saturn . When HP did an updated version of that calculator, that CPU was very, very old and could no longer be manufactured, so they built an emulator for the old CPU and ran it on a Samsung ARM.
The TI calculators. Overpriced for what little they do, but classic. I still get happy when i find an old TI graphic calculator at goodwill for 5 bucks.
"Imagine trying to type all those things..." he said as I laughed about my numberous hundred-plus line ti-84 "programs" i made in math+chemistry while I was trying to look like i was doing work....
it's still ridiculous how much they charge for these things. yes, i get it, most districts use them because they want something standardized, but i still hate how they jack the price so high for something that literally any device could do nowadays
Wow, this popped up whilst working on a 3d surface plot in python from a csv file. Yeah I'm your age and decided to learn python on the fly. All the cool kids are doing it. PS: Long live the Casio FX 7000g.
Would have been nice to see how the ARM emits drawing commands. Since raspberry pi's ceased production years ago, there is a market for a crummy 115200 python console now.
Ben needs to add an “X-Ray” function that explains the references that he constantly drops… or maybe we need a drinking game (drink whenever you don’t get one?). Keep up the good / hilarious work, Ben!
I did a similar thing to this setup on my home brew Z180 computer with a Pi Pico running micropython. The Z180 sends and receives serial ASCII chars as python commands to the Pico and the Pico runs the python code. A second Z180 serial port connects to putty terminal for keyboard input and display output.
Not surprising that Texas Instruments is still continuing to sell the same old calculators. It's like they got to a certain level of performance and decided not to improve anymore. Most people these days have cell phones, and Python on the phone is substantially superior.
Honestly surprised TI even still uses a qfn main cpu instead of an smd one. Also imagine having a backwards-compatible calculator and not letting the users run older programs... Why though? It should fit on the screen
Version 1 of TI's ASIC was a small BGA chip. They switched to QFN for the second major iteration (there was a minor revision that eliminated custom interrupt service routine support, just because they're dicks). My guess is that QFN packaging is slightly cheaper than BGA, and they needed BGA for the first version because it used a parallel flash, requiring 32 pins (22 address, eight data, two control) just for the flash interface; they're now using a QSPI flash.
FYI the header labelled T46 is almost certainly the Arm Serial Wire Debug port. Could have a lot of fun with that unless the chip has the debug disabled.
Micropython and Circuitpython are both highly optimized for their targets, which means the poor performance is largely due to the latency hit the ez80 takes during communications with the coprocessor.
I refuse to use circuit python as long as 'lady ada' charges 20 dollars for a single dip led. Companies like adafruit make it impossible for kids in lower income families to get into electronics. I'm on a disability pension and I donate free learning kits all the time, not for thanks but because someone has to. I don't see or hear of many others doing it. All of my creator friends have (basically become sponsored review channels) and hoard stuff they will never use instead of donating anonymously like me. I know im contradicting myself but it's rampant. Who needs to keep 8 different arduino kits from every manufacturer and a million Chinese multimeters. That's my rant for the week haha.
@@jstro-hobbytech Lada Ada is an absolute icon and I won't have you besmirch her name. Have at thee! I kid. I've donated parts, myself, though mostly to specific devs who couldn't afford a part they need. I don't get anything free, though, that would be nice. I find most of adafruit's offerings to be quite affordable, and I am low income, as well. I _do_ prefer micropython, though; it is more generically designed and therefore easier to deploy on mismatched fleets of devices.
@talosthoren5409 I can respect your opinion. I live in Canada as well and amazon is the only real place to get adafruit stuff. I paid 60 dollars for a bno055 module, on sale. Haha. You make a lot of good points and I can agree with you to a point as all the framework stuff she has written for people using the arduino ide. 15usd for a single led is madness though. Haha Cheers man. Thank you for not taking what I said to be trolling and providing real opinions based on your experience. I wish everyone was the same.
Python has some of the drawbacks of being interpreted, but it is very good for quickly prototyping an idea, and it's the best solution for onetime use solutions. I tell people not to learn easy languages first because it makes languages like C seem cumbersome.
to be fair though, Python is so much nicer to program with compared to BASIC, let alone TI-Basic heh. Personally I just wish there was an editor+toolchain for doing C or assembly directly on the TI-84, that'd be just absolutely beautiful but one can dream.
Python is more of a super calculator. Its not really mean for programmers, moreso its for data anylists, machine learning engineers, and other more math intensive applications. Programmers shouldnt even really touch it to be honest, other scripting languages like lua, perl, or even shell script can usually get the job done, often quicker (at least in my opinion).
I mean there is no reason you couldn't port Circuit/MicroPython to the eZ80 (the main cpu in the TI), but it is a 24 bit (not 32 bit ALU). But apparently it was easier/cheaper to add a M0 than do that
31:02 Or just downloading Python interpreter on desktop, or online interpreter, or something on mobile phone... pretty much ANYTHING other that this XD
I have to imagine that, because the new car was mentioned and remained unnamed, there will be a video doing a teardown. Ben is a master of foreshadowing. I await this video with great anticipation.
Now, try using quit() to see if you drop to a shell. It could be interesting to see if you can flash the ARM chip with different things and see if you could use it with the calculator. Like a mini Linux session or emulator running alongside zOS. You could always capture what's being programmed to the ARM chip (Or possibly SRAM) on the initialization of Python.
Remember the python module? It was a small external module that connected to the non-Python T84PCE's USB mini port, it was equipped with tbe virtually same Atmel SAMD21 MCU & communicated via USB as a terminal.
Another amazing vid yet again, Ben! The highlight of the video was the keyboard being "Washable". Brilliant, place that inside a washing machine set to 30c. It will make a great video. :)
Why don't they just use a modern ARM chip and emulate that Z80 in software? HP has done exactly that, they emulated the old Saturn calculator CPU and the result was much faster than the vintage models.
This ought to be fun! I bought one a couple days before you asked on twitter if anyone knew what was inside it- I was going to crack it open for you, but, life has been hectic... now I don't have to =)
Omg!!!! Mod chip. TI Calculator. Python. CIRCUIT Python!!!!! This has all the things. It has arrived the calculator of my dreams 😍😍😍😍 Arm co-processor. Color screen. What!!!! I guess some dreams really do come true 🥺. Not even joking.
I have a 82 right in front of me but I can’t find out what cord/program to use to install programs on it. I’ve searched but most the info is from the 90s but even with using Mac Os9 I still can’t get my graph link cable to work
@@mountainmanmcbeachfront5296 Have you tried using TiLP? If you have one of the clear plastic USB->2.55mm cables (referred to as "silverlink" by the community), that's as good as it gets cable wise. The serial graphlink cables are a huge pain to work with.
Hi Ben, I'm at minute 17, and I dunno if anyone else mentioned this (or if you figure it out later) but those 1B (ESC) 5B ([) sequences are old terminal escape codes, sometimes called ANSI escape codes, or 'termcap' (terminal capability) codes, and they go all the way back to the mainframe days. Your program could inline these sequences to move the cursor in two dimensions, clear the screen, change character sets, colorize text (if your terminal supported that), or even do simple graphics. It's a pretty archaic way of doing things but it still features in modern UNIX-ish systems as a way to iron out signalling differences between (for example) PuTTY on a Windows host or Terminator on a Linux host or (God help you) using a terminal emulator to pretend you've got an ancient VT102 dumb terminal when talking to the serial diagnostic port on some ancient embedded controller... like this one. en.wikipedia.org/wiki/ANSI_escape_code
Oh, never mind, got to minute 19, you figured it out. Sorry. I shouldn't have doubted you. I swear sometimes I think nobody under the age of 50 is going to remember this stuff... and I'm only 48.
Hey. I believe the escape code "ESC[F" you were seeing is the "Cursor previous line" command, as listed in the wikipedia article under "CSI sequences" ( en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_Sequence_Introducer)_sequences ). The CSI sequence being the ESC[ bit. It takes in an optional `n` argument preceding `F` for the number of lines to move upwards, omitting it (as is the case with the sequence witnessed in the video) will default the command to n=1.
TI loves UART in their calculators. The little 2.5mm transfer cables are also UART, with RX/TX and GND. I wouldn't be surprised at all if they're just using the link port BCALLs written 40 years ago for all of this. It would explain the huge gaps. TI's code uses extremely bulky routines for accessing their equivalent of syscalls. Something like 1000 cycles per call, minimum. 0x3E is >, so that initial return at 17:25 is " >>> " which is just the python REPL prompt. Honestly I'm surprised they didn't go for an arm based TI-84+ with the same emulator they made for the nspire series. It would outperform the ez80 by a pretty wide margin if they just removed the speed cap, and it could just run the same FreeRTOS on top. A python interpreter running there would be easy, and much higher performance. It would probably have a lower BOM cost too, considering those ez80 chips cost $10-20 each, and much better ARM cortex m4 chips can be had for half that.
One hilarious consequence of this is that, if you used assembly to directly bit-bang the port the python chip was hooked to, you could get that interface running dramatically faster.
@@happycube Using their own microcontrollers rather than zilog's is almost certainly cheaper. The ez80 is a relatively low-volume specialty line of drop-in compatible replacements for ancient z80 CPUs.
What year did that scope come out Ben? I've been waiting for a second hand one at a decent price to pop up but the Canadian loony makes it prohibitively expensive haha. I traded a 3d printer dor a tds2002c but i want an mdo. I have a decent rigol mso5354 but tektronix scopes are just classy. Haha Didn't keysight give you the obligatory free scope yet?
You should re-upload the example programs to see how ti_plotlib communicates with the Z80. Based on the speed of the plot when you ran it near the beginning, it might also be using escape sequences to send graphics primitives back to Z80 over the UART like an old Tektronix 4105 terminal.
Yes, that's correct - it uses a CSI escape sequence with a final character of G to send graphics commands back to the main processor. I haven't worked out exactly how the arguments work for it yet, though.
What about a calculator that embeds an ESP32 relaying over wifi with a cloud service providing remotely controlled instances of Chrome that renders equations with Desmos, sends the data back as PNG, which the ESP32 decodes and feeds pixel by pixel to the main Z80 over serial?
Yes, but Z80, 8080 (yes them too) and 65C02 are considered microcontrollers now. Some have even timers and watchdogs. I assembled a Chinese digital clock kit that I earned on a prize draw on an event that had a customized 8080 with internal ROM for things like these. The chip is also made in China.
@@agranero6 OK, I don't know about the Z80 line but the 65C02 that is still made today is *NOT* a micro-controller in ANY way. Not even a little bit. It's a full CPU. I've literally put them in Apple II's (with slight re-routing of pins) and they work. In fact, the Apple IIgs and IIe (expanded) work with the 65C02.
@@cbmeeks I said they are "considered", because of memory and speed, and because many are used this way. Yes those with internal RAM probably could not substitute the original ones. But those without it can surely be used for that, even with advantages. I never saw a new "8080" that could. But several "Z80" can. I like the 6502 too, the several addressing modes make it very easy to use and powerful. The magic of those machines is that you could fully undertand all that was happening.
@@agranero6 I don't know who or why someone would consider a 6502 or it's variants like the 65C02 a mico-controller any more than I would consider a micro-controller an FPGA. They are not the same.
@@cbmeeks The is no "official" definition of microcontroller, except when you have a Harvard architecture and watchdog counters when there is little doubt. The definition is usulally usage dependent: when it is used as a microcontroller it is one, when it is used as a CPU it is not. And yes FPGAs can be used as ANYTHING, even as a 6502. They are much used in avionics (because of the low quantity of production) and osciloscopes (and much, much more). And as 6502 is simple, has powerful addressing modes and a huge toolset it is not strage they are used tnis way. Besides addressing 64k allows easily to make versions that have integrated memory blurring more the lines.
