When the Commodore 64 was released in 1982, it was a masterpiece of engineering. It had capabilities far outstripping other home computers, and that was all due to two fancy chips inside the C64. The VIC-II, the video chip for the C64, had sprites and scrolling, all stuffed into a single bit of silicon. The SID chip was a complete synthesizer on a chip. These bits of silicon made the C64 the best selling computer of all time, but have also stymied efforts to emulate a complete C64 system on a microcontroller.
The inspiration for this project comes from a reverse-engineered SID chip that was ported to the Teensy 3.2. The SID chip is the make it or break it feature of any C64 emulation, but the Teensy 3.2 didn’t have enough RAM for the most recent versions of reSID. With the release of the Teensy 3.6, [Frank] figured the increased amount of RAM would allow a complete C64 system, so he built it.
The new C64 emulator uses a Teensy 3.6, with a small add-on ‘shield’ (or whetever we’re calling them) to provide connectors for joysticks and the Commodore IEC bus. There’s audio out, support for USB keyboards, and support for an IL9341 SPI display or a regular ‘ol VGA display.
The entire development of this Commodore emulator has been documented over on the PJRC forums, and all the code is over on GitHub. It’s a fantastic piece of work, and as the video (below) shows, this is a real Commodore 64 that fits in your pocket.
Sometimes the best part of building something is getting to rebuild it again a little farther down the line. Don’t tell anyone, but sometimes when we start a project we don’t even know where the end is going to be. It’s a starting point, not an end destination. Who wants to do something once when you could do it twice? Maybe even three times for good measure?
That’s what happened when [Ryan] decided to build a wireless “party button” for his kids. Tied into his Home Assistant automation system, a smack of the button plays music throughout the house and starts changing the colors on his Philips Hue lights. His initial version worked well enough, but in the video after the break, he walks through the evolution of this one-off gadget into a general purpose IoT interface he can use for other projects.
The general idea is pretty simple, the big physical button on the top of the device resets the internal ESP8266, which is programmed to connect to his home WiFi and send a signal to his MQTT server. In the earlier versions of the button there was quite a bit of support electronics to handle converting the momentary action of the button to a “hard” power control for the ESP8266. But as the design progressed, [Ryan] realized he could put the ESP8266 to deep sleep after it sends the signal, and just use the switch to trigger a reset on the chip.
Additional improvements in the newer version of the button include switching from alkaline AA batteries to a rechargeable lithium-ion pack, and even switching over to a bare ESP8266 rather than the NodeMCU development board he was using for the first iteration.
The various development boards such as the NodeMCU or Wemos D1 make working with the ESP8266 an absolute breeze. If they have a downside, it is that they are larger than the bare ESP2866, and of course cost a bit more. Just as with the Arduino, once you have the wiring sorted out and the code more or less finalized, your best bet is to ditch the unnecessary support hardware and use the bare module to save space and money in your final design.
Unfortunately, the ESP8266 form factor isn’t terribly forgiving when it comes time for hooking up a programmer. Rather than having to solder a serial adapter to the chip to flash it, [Ryan] came up with a slick 3D printed programming jig that uses pogo pins. If you have to program these boards in bulk, a jig like this can save a massive amount of time and aggravation.
Beyond the 3D printed holder for the pogo pins, this programmer uses a FTDI USB-to-serial adapter, a couple passive components to smooth out the power going into the chip, and a couple buttons.
In the video after the break, [Ryan] walks through the many iterations it took to get the 3D printed aspect of the jig worked out. The design went through a few rather large revisions, including one that fundamentally changed the whole form factor. Even with the jig now working, he mentions that he might circle back around and try it from a different angle.
Lightning storm detectors have been around for a surprisingly long time. The early designs consisted of a pair of metal bells and a pendulum. When there was a charge applied, for example by connecting one bell to the ground and the other to a lightning rod, the bells would ring when a lightning storm was close by. In the mid 18th century, these devices were only practical for demonstration and research purposes, but very likely represent the earliest devices that convert electrostatic charge to mechanical force. A bit over a hundred years later, the first lightning detector was considered by some as the first radio receiver as well.
Over at RCgroups, user [Cesco] has shared a very interesting project which uses the ever-popular ESP8266 as both a transmitter and receiver for RC vehicles. Interestingly, this code makes use of the ESP-Now protocol, which allows devices to create a mesh network without the overhead of full-blown WiFi. According to the Espressif documentation, this mode is akin to the low-power 2.4GHz communication used in wireless mice and keyboards, and is designed specifically for persistent, peer-to-peer connectivity.
Switching an ESP8266 between being a transmitter or receiver is as easy as commenting out a line in the source code and reflashing the firmware. One transmitter (referred to as the server in the source code) can command eight receiving ESP8266s simultaneously. [Cesco] specifically uses the example of long-range aircraft flying in formation; only coming out of the mesh network when it’s time to manually land each one.
[Cesco] has done experiments using both land and air vehicles. He shows off a very hefty looking tracked rover, as well as a quickly knocked together quadcopter. He warns the quadcopter flies like “a wet sponge”, but it does indeed fly with the ESP’s handling all the over the air communication.
To be clear, you still need a traditional PPM-compatible RC receiver and transmitter pair to use his code. The ESPs are simply handling the over-the-air communication. They aren’t directly responsible for taking user input or running the speed controls, for example.
Sometimes you have to switch a light. Maybe it’s an LED but sometimes it’s mains-powered. That’s not too hard, a transistor and a relay should do it. If you have to switch more lights, that’s not too bad either, as long as your microcontroller has enough free GPIOs. But, if you need to switch a large number of lights, like 256 of them, for example, you’re going to need something else.
The build is interesting, both from a technical point of view and from an artistic one. It looks like it uses more than a mile of wiring, too. The source code is also available on the project page if you happen to have a need for switching a huge number of lightbulbs. Incandescent blulbs aren’t only good for art installations and lamps, though, they can also be used in interesting oscillator circuits too.
The PocketBeagle single-board computer is now a few months old, and growing fast like its biological namesake. An affordable and available offering in the field of embedded Linux computing, many of us picked one up as an impulse buy. For some, the sheer breadth of possibilities can be paralyzing. (“What do I do first?”) Perhaps a development board can serve as a starting point for training this young puppy? Enter the BaconBits cape.
When paired with a PocketBeagle, everything necessary to start learning embedded computing is on hand. It covers the simple basics of buttons for digital input, potentiometer for analog input, LEDs for visible output. Then grow beyond the basics with an accelerometer for I²C communication and 7-segment displays accessible via SPI. Those digging into system internals will appreciate the USB-to-serial bridge that connects to PocketBeagle’s serial console. This low-level communication will be required if any experimentation manages to (accidentally or deliberately) stop PocketBeagle’s standard USB network communication channels.
BaconBits were introduced in conjunction with the E-ALE (embedded apprentice Linux engineer) training program for use in hands-on modules. The inaugural E-ALE session at SCaLE 16X this past weekend had to deal with some last-minute hiccups, but the course material is informative and we’re confident it’ll be refined into a smooth operation in the near future. While paying for the class will receive built hardware and in-person tutorials to use it, all information – from instructor slides to the BaconBits design – is available on Github. Some of us will choose to learn by reading the slides, others will want their own BaconBits for independent experimentation. And of course E-ALE is not the only way to learn more about PocketBeagle. Whichever way people choose to go, the embedded Linux ecosystem will grow, and we like the sound of that!
By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more