Gaming In Different Languages

One of the perks of using older hardware is its comparative simplicity and extensive documentation. After years or decades of users programming on a platform, the amount of knowledge available for it can become extensive. This is certainly the case with the 6502 microprocessor, used in old Apple computers and some video game systems from the ’80s. The extensive amount of resources available make it a prime candidate in exploring various programming languages, and their advantages and disadvantage.

This project looks into those differences using a robot game, which has been programmed four different ways in three languages. [Joey] created the game in Python first and then began to port it to the 65C02, a CMOS variant of the 6502. The first iteration is its assembly language, and then a second iteration with optimized assembly code. From there, he ports it to C and then finally to Forth. Each version of the game is available to play in a browser using an emulator to run the 6502 hardware.

Since the games run in the browser, other tools are available to examine the way the game runs in each language. Registers can be viewed in real time, as well as the values stored in the memory. It’s an interesting look at an old piece of hardware and of its inner workings. For an even deeper dive into the 6502, it’s possible to build a working computer on breadboards using one.

Sparklines For Your ESP32 Projects

On a typical microcontroller project we may only have access to a relatively tiny screen. Information display can be a challenge, but it’s one that may be made easier by [0xPIT]’s ESParklines library for Espressif processors using the Arduino framework.

A sparkline is a simple line graph without annotations (like axes or units) intended to fit within the flow of text. They’re largely associated today with the statistician Edward Tufte, and if you’ve not encountered them or Tufte before then we suggest you’ll enjoy educating yourself.

It’s a simple enough library and it comes with example code. Usefully it maintains a data buffer all of its own allowing simple updating, and as well as the examples there is a YouTube video we’ve put below the fold showing graphs evolving as more information is added to them. We’re curious about one thing though, it’s billed as an ESP library, for either the ESP8266 or the ESP32, but we can’t find any ESP-specific code in there and neither could our friendly ESP-guru. Have we missed something? The comments are below if you can shed any light.

Continue reading “Sparklines For Your ESP32 Projects”

ESP32-S2 Hack Chat With Adafruit

Join us on Wednesday, May 6 at noon Pacific for the ESP32-S2 Hack Chat with Limor “Ladyada” Fried and Scott Shawcroft!

When Espressif released the ESP8266 microcontroller back in 2014, nobody could have predicted how successful the chip was to become. While it was aimed squarely at the nascent IoT market and found its way into hundreds of consumer devices like smart light bulbs, hackers latched onto the chip and the development boards it begat with gusto, thanks to its powerful microcontroller, WiFi, and lots of GPIO.

The ESP8266 was not without its problems, though, and security was always one of them. The ESP32, released in 2016, addressed some of these concerns. The new chip added another CPU core, a co-processor, Bluetooth support, more GPIO, Ethernet, CAN, more and better ADCs, a pair of DACs, and a host of other features that made it the darling of the hacker world.

Now, after being announced in September of 2019, the ESP32-S2 is finally making it into hobbyist’s hands. On the face of it, the S2 seems less capable, with a single core and neither Bluetooth nor Ethernet. But with a much faster CPU, scads more GPIO, more ADCs, a RISC-V co-processor, native USB, and the promise of very low current draw, it could be that the ESP32-S2 proves to be even more popular with hobbyists as it becomes established.

To talk us through the new chip’s potential, Limor “Ladyada” Fried and Scott Shawcroft, both of Adafruit Industries, will join us on the Hack Chat. Come along and learn everything you need to know about the ESP32-S2, and how to put it to work for you.

join-hack-chatOur Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, May 6 at 12:00 PM Pacific time. If time zones have got you down, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Continue reading “ESP32-S2 Hack Chat With Adafruit”

Breaking Into A Secure Facility: STM32 Flash

In a perfect world, everything would be open source. Our current world, on the other hand, has a lot of malicious actors and people willing to exploit trade secrets if given the opportunity, so chip manufacturers take a lot of measures to protect their customers’ products’ firmware. These methods aren’t perfect, though, as [zapb] shows while taking a deeper look into an STM microcontroller.

The STM32F0 and F1 chips rely on various methods of protecting their firmware. The F0 has its debug interface permanently switched off, but the F1 still allows users access to this interface. It uses flash memory read-out protection instead, which has its own set of vulnerabilities. By generating exceptions and exploiting the intended functions of the chip during those exceptions, memory values can be read out of the processor despite the memory read-out protection.

This is a very detailed breakdown of this specific attack on theses controllers, but it isn’t “perfect”. It requires physical access to the debug interface, plus [zapb] was only able to extract about 94% of the internal memory. That being said, while it would be in STM’s best interests to fix the issue, it’s not the worst attack we’ve ever seen on a piece of hardware.

A Super-Brain For An E-bike

There’s no better way of improving a project than logging data to make informed decisions on future improvements. When it came to [Brian]’s latest project, an electric bike, he wanted to get as much data as he could from the time he turned it on until the time he was finished riding. He turned to a custom pyBoard-based device (and wrote it up on Hackaday.io), but made it stackable in order to get as much information from his bike as possible.

This isn’t so much an ebike project as it is about a microcontroller platform that can be used as a general purpose device. All of the bike’s controls flow through this device as a logic layer, so everything that can possibly be logged is logged, including the status of the motor and battery at any given moment. This could be used for virtually any project, and the modular nature means that you could scale it up or down based on your specific needs. The device is based on an ARM microcontroller so it has plenty of power, too.

While the microcontroller part is exceptionally useful ([Brian] talks about some of its other uses here and gives us even more data on his personal webpage), we shouldn’t miss the incredible bike that [Brian] built either. It has a 3 kW rear hub motor and can reach speeds of around 60 mph. While we let the commenters below hash out the classic argument of “bicycle vs. motorcyle” we’ll be checking out some electric vehicles that are neither.

The TMS1000: The First Commercially Available Microcontroller

We use a microcontroller without a second thought, in applications where once we might have resorted to a brace of 74 logic chips. But how many of us have spared a thought for how the microcontroller evolved? It’s time to go back a few decades to look at the first commercially available microcontroller, the Texas Instruments TMS1000.

Imagine A World Without Microcontrollers

The Texas Instruments Speak And Spell from 1978 was a typical use for the TMS1000.
The Texas Instruments Speak & Spell from 1978 was a typical use for the TMS1000. FozzTexx (CC-SA 4.0)

It’s fair to say that without microcontrollers, many of the projects we feature on Hackaday would never be made. Those of us who remember the days before widely available and easy-to-program microcontrollers will tell you that computer control of a small hardware project was certainly possible, but instead of dropping in a single chip it would have involved constructing an entire computer system. I remember Z80 systems on stripboard, with the Z80 itself alongside an EPROM, RAM chips, 74-series decoder logic, and peripheral chips such as the 6402 UART or the 8255 I/O port. Flashing an LED or keeping an eye on a microswitch or two became a major undertaking in both construction and cost, so we’d only go to those lengths if the application really demanded it. This changed for me in the early 1990s when the first affordable microcontrollers with on-board EEPROM came to market, but by then these chips had already been with us for a couple of decades.

It seems strange to modern ears, but for an engineer around 1970 a desktop calculator was a more exciting prospect than a desktop computer. Yet many of the first microcomputers were designed with calculators in mind, as was for example the Intel 4004. Calculator manufacturers each drove advances in processor silicon, and at Texas Instruments this led to the first all-in-one single-chip microcontrollers being developed in 1971 as pre-programmed CPUs designed to provide a calculator on a chip. It would take a few more years until 1974 before they produced the TMS1000, a single-chip microcontroller intended for general purpose use, and the first such part to go on sale. Continue reading “The TMS1000: The First Commercially Available Microcontroller”

’75 Nixie Multimeter As Digital Dice

For the casual Monopoly or Risk player, using plain six-sided dice is probably fine. For other games you may need dice with much more than six sides, and if you really want to go overboard you can do what [John] did and build electronic dice with a random number generator if you really need to remove the pesky practice of rolling physical dice during your games of chance.

The “digital dice” he built are based on a multimeter from 1975 which has some hardware in it that was worth preserving, including a high quality set of nixie tubes. Nixies can be a little hard to come by these days, but are interesting pieces of hardware in their own right. [John] added some modern hardware to it as well, including an AVR microcontroller that handles the (pseudo) random number generation. A hardware switch tells the microcontroller how many sides the “die” to be emulated will need, and then a button generates the result of the roll.

This is a pretty great use for an old piece of hardware which would otherwise be obsolete by now. [John] considers this a “Resto-Mod” and the finish and quality of the build almost makes it look all original. It’s certainly a conversation piece at the D&D sessions he frequents.