Flashing TI Chips With An ESP

April 3, 2022 by Bryan Cockfield 29 Comments

Texas Instruments is best known to the general public for building obsolete calculators and selling them at extraordinary prices to students, but they also build some interesting (and reasonably-priced) microcontrollers as well. While not as ubiquitous as Atmel and the Arduino platform, they can still be found in plenty of consumer electronics and reprogrammed, and [Aaron] aka [atc1441] demonstrates how to modify them with an ESP32 as an intermediary.

Specifically, the TI chips in this build revolve around the 8051-core microcontrollers, which [Aaron] has found in small e-paper price tags and other RF hardware. He’s using an ESP32 to reprogram the TI chips, and leveraging a web server on the ESP in order to be able to re-flash them over WiFi. Some of the e-paper displays have built-in header pins which makes connecting them to the ESP fairly easy, and once that’s out of the way [Aaron] also provides an entire software library for interacting with these microcontrollers through the browser interface.

Right now the project supports the CC2430, CC2510 and CC1110 variants, but [Aaron] plans to add support for more in the future. It’s a fairly comprehensive build, and much better than buying the proprietary TI programmer, so if you have some of these e-paper displays laying around the barrier to entry has been dramatically lowered. If you don’t have this specific type of display laying around, we’ve seen similar teardowns and repurposing of other e-paper devices in the past as well.

Continue reading “Flashing TI Chips With An ESP” →

Talking To A Texas Instruments Calculator

March 17, 2022 by Bryan Cockfield 20 Comments

Texas Instruments is a world-class semiconductors company, but unfortunately what they are best known for among the general public is dated consumer-grade calculators thanks to entrenched standardized testing. These testing standards are so entrenched, in fact, that TI has not had to update the hardware in these calculators since the early 90s. They still run their code on a Z80 microcontroller, but [Ben Heck] found himself in possession of one which has a modern ARM coprocessor in it and thus can run Python.

While he’s not sure exactly what implementation of Python the calculator is running, he did tear it apart to try and figure out as much as he could about what this machine is doing. The immediately noticeable difference is the ARM coprocessor that is not present in other graphing calculators. After some investigation of test points, [Ben] found that the Z80 and ARM chips are communicating with each other over twin serial lines using a very “janky” interface. Jankiness aside, eventually [Ben] was able to wire up a port to the side of the calculator which lets him use his computer to send Python commands to the device when it is in its Python programming mode.

While there are probably limited use cases for 1980s calculators to run Python programs, we can at least commend TI for attempting to modernize within its self-built standardized testing prison. Perhaps this is the starting point for someone else to figure out something more useful to put these machines to work with beyond the classroom too. We’ve already seen some TI-84s that have been modified to connect to the Internet, for example.

Thanks to [Nikša] for the tip!

Continue reading “Talking To A Texas Instruments Calculator” →

Code Wrong: Expand Your Mind

January 29, 2022 by Elliot Williams 24 Comments

The really nice thing about doing something the “wrong” way is that there’s just so much variety! If you’re doing something the right way, the fastest way, or the optimal way, well, there’s just one way. But if you’re going to do it wrong, you’ve got a lot more design room.

Case in point: esoteric programming languages. The variety is stunning. There are languages intended to be unreadable, or to sound like Shakespearean sonnets, or cooking recipes, or hair-rock ballads. Some of the earliest esoteric languages were just jokes: compilations of all of the hassles of “real” programming languages of the time, but yet made to function. Some represent instructions as a grid of colored pixels. Some represent the code in a fashion that’s tantamount to encryption, and the only way to program them is by brute forcing the code space. Others, including the notorious Brainf*ck are actually not half as bad as their rap — it’s a very direct implementation of a Turing machine.

So you have a set of languages that are designed to be maximally unlike each other, or traditional programming languages, and yet still be able to do the work of instructing a computer to do what you want. And if you squint your eyes just right, and look at as many of them all together as you can, what emerges out of this blobby intersection of oddball languages is the essence of computing. Each language tries to be as wrong as possible, so what they have in common can only be the unavoidable core of coding.

While it might be interesting to compare an contrast Java and C++, or Python, nearly every serious programming language has so much in common that it’s just not as instructive. They are all doing it mostly right, and that means that they’re mostly about the human factors. Yawn. To really figure out what’s fundamental to computing, you have to get it wrong.

A Programming Language To Express Programming Frustration

December 14, 2021 by Bryan Cockfield 26 Comments

Programming can be a frustrating endeavor. Certainly we’ve all had moments, such as forgetting punctuation in C or messing up whitespace in Python. Even worse, an altogether familiar experience is making a single change to a program that should have resulted in a small improvement but instead breaks the program. Now, though, there’s a programming language that can put these frustrations directly into the code itself into a cathartic, frustration-relieving syntax. The language is called AHHH and it’s quite a scream.

While it may not look like it on the surface, the language is Turing complete and can be used just like any other programming language. The only difference is that there are only 16 commands in this language which are all variants of strings of four capital- or lower-case-H characters. The character “A” in the command “AHHH” starts the program, and from there virtually anything can be coded as a long, seemingly unending scream. The programming language is loosely related to COW which uses various “moos” to create programs instead of screams, and of course is also distantly related to brainfuck which was an esoteric programming language created in order to have the smallest possible compiler.

We can’t really recommend that beginner programmers start to learn this language instead of something more practical like Python, esoteric languages like these can teach us a lot about the way that computers work. This language, for example, lets you code in pixels instead of characters. Others are more for fun such as this language which turns your code into an ’80s rock ballad.

Thanks to [Kyle F] for the tip!

Hackaday Podcast 146: Dueling Trackballs, Next Level BEAM Robot, Take Control Of Your Bench, And Green Programming

November 26, 2021 by Elliot Williams 3 Comments

Postpone your holiday shopping and spend some quality time with editors Mike Szczys and Elliot Williams as they sift through the week in Hackaday. Which programming language is the greenest? How many trackballs can a mouse possibly have? And can a Bluetooth dongle run DOOM? Join us to find out!

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (52 MB)

Continue reading “Hackaday Podcast 146: Dueling Trackballs, Next Level BEAM Robot, Take Control Of Your Bench, And Green Programming” →

Palm OS: Reincarnate

November 11, 2021 by Matthew Carlson 26 Comments

[pmig96] loves PalmOS and has set about on the arduous task of reimplementing PalmOS from scratch, dubbing it Pumpkin OS. Pumpkin OS can run on x86 and ARM at native speed as it is not an emulator. System calls are trapped and intercepted by Pumpkin OS. Because it doesn’t emulate, Palm apps currently need to be recompiled for x86, though it’s hoped to support apps that use ARMlets soon. Since there are over 800 different system traps in PalmOS, he hasn’t implemented them all yet.

Generally speaking, his saving grace is that 80% of the apps only use 20% of the API. His starting point was a script that took the headers from the PalmOS SDK and converted them into functions with just a debug message letting him know that it isn’t implemented yet and a default return value. Additionally, [pmig96] is taking away some of the restrictions on the old PalmOS, such as being limited to only one running app at a time.

As if an x86 desktop version wasn’t enough, [pmig96] recompiled Pumpkin OS to a Raspberry Pi 4 with a ubiquitous 3.5″ 320×480 TFT SPI touch screen. Linux maps the TFT screen to a frame buffer (dev/fb0 or dev/fb1). He added a quick optimization to only draw areas that have changed so that the SPI writes could be kept small to keep the frame rate performance.

[pmig96] isn’t the only one trying to breathe some new life into PalmOS, and we hope to see more progress on PumpkinOS in the future.

Python Ditches The GILs And Comes Ashore

November 3, 2021 by Matthew Carlson 38 Comments

The Python world has been fractured a few times before. The infamous transition from version 2 to version 3 still affects people today, and there could be a new schism in the future. [Sam Gross] proposed a solution to drop the Global ~~Interrupt~~ Interpreter Lock (GIL), which would have enormous implications for many projects that leverage the CPython internals, such as Pandas and NumPy.

The fact that Python is interpreted is a double edge sword. It means there can be different runtimes, such as Pyston, Cinder, MicroPython, PyPy, and others, that might support the whole language, a specific version, or a subset. But if you’re using Python, you’re probably running CPython. And it has something known as global interpreter lock that affects threaded code. In a nutshell, only one thread can run in the interpreter at a time. There are some ways around it, such as moving performance-critical sections to C or having multiple interpreters. However, most existing solutions come with considerable downsides. Continue reading “Python Ditches The GILs And Comes Ashore” →