Back in the late 1970s and early 1980s when you turned on a PC, more often than not, you’d get a Basic prompt. Most people would then load a game from a tape, but if you were inclined to program you could just start writing. [Richpl] wanted that same experience and thus PyBasic was born. Along with some other Github contributors, the system has grown quite a bit and would be a good start at porting classic games or creating a replica vintage computer.
The interpreter lacks specialized hardware-specific features such as sound and graphics, of course, but then again, you could add them. It does have file I/O and also includes some interesting features like an analog of C’s ternary operator.
I once asked a software developer at work how many times we called fork() in our code. I’ll admit, it was a very large project, but I expected the answer to be — at most — two digits. The developer came back and read off some number from a piece of paper that was in the millions. I told them there was no way we had millions of calls to fork() and, of course, we didn’t. The problem was the developer wasn’t clear on the difference between a regular expression and a glob.
Tools like grep use regular expressions to create search patterns. I might write [Hh]ack ?a ?[Dd]ay as a regular expression to match things like “HackaDay” and “Hack a day” and, even, “Hackaday” using a tool like grep, awk, or many programming languages.
Generally speaking, we like our computing devices to remain on and active the whole time we’re using them. But there are situations, such as off-grid devices that run on small solar cells, where constant power is by no means a guarantee. That’s where the concept of intermittent computing comes into play, and now thanks to the BFree project, you can develop Python software that persists even when the hardware goes black.
Implemented as a shield that attaches to a Adafruit Metro M0 Express running a modified CircuitPython interpreter, BFree automatically makes “checkpoints” as the user’s code is running so that if the power is unexpectedly cut, it can return the environment to a known-good state instantaneously. The snapshot of the system, including everything from the variables stored in memory to the state of each individual peripheral, is stored on the non-volatile FRAM of the MSP430 microcontroller on the BFree board; meaning even if the power doesn’t come back on for weeks or months, the software will be ready to leap back into action.
In addition to the storage for system checkpoints, the BFree board also includes energy harvesting circuity and connections for a solar panel and large capacitor. Notably, the system has no provision for a traditional battery. You can keep the Metro M0 Express plugged in while developing your code, but once you’re ready to test in the field, the shield is in charge of powering up the system whenever it’s built up enough of a charge.
The product of a collaboration between teams at Northwestern University and Delft University of Technology, BFree is actually an evolution of the battery-free handheld game they developed around this time last year. While that project was used to raise awareness of how intermittent computing works, BFree is clearly a more flexible platform, and is better suited for wider experimentation.
We’ve seen a fair number of devices that store up small amounts of energy over the long term for quick bouts of activity, so we’re very interested to see what the community can come up with when that sort of hardware is combined with software that can be paused until its needed.
It isn’t news that [s0lly] likes to do ray tracing using Microsoft Excel. However, he recently updated his set up to use functions in a C XLL — a DLL, really — to accelerate the Excel rendering. Even if ray tracing isn’t your thing, the technique of creating custom high-performance Excel functions might do you some good somewhere else.
We’ve seen [s0lly’s] efforts before, and you can certainly see that the new technique speeds things up and produces a better result, which isn’t especially surprising. In addition to being faster, the new routines produce more detail.
[SSZCZEP] had a tough time understanding ray tracing to create 3D-like objects on a 2D map. So once he figured it out, he wrote a tutorial he hopes will be more accessible for those who may be struggling themselves.
If you’ve ever played Wolfenstein 3D you’ll have seen the technique, although it crops up all over the place. The tutorial borrows an animated graphic from [Lucas Vieira] that really shows off how it works in a simplified way. The explanation is pretty simple. From a point of view — that is a camera or the eyeball of a player — you draw rays out until they strike something. The distance and angle tell you how to render the scene. Instead of a camera, you can also figure out how a ray of light will fall from a light source.
There is a bit of math, but also some cool interactive demos to drive home the points. We wondered if Demos 3 and 4 reminded anyone else of an obscure vector graphics video game from the 1970s? Most of the tutorial is pretty brute force, calculating points that you can know ahead of time won’t be useful. But if you stick with it, there are some concessions to optimization and pointers to more information.
Overall, a lot of good info and cool demos if this is your sort of thing. While it might not be the speediest, you can do ray tracing on our old friend the Arduino. Or, if you prefer, Excel.
These days we expect even the cheapest of burner smartphones to feature a multi-core processor, at least a gigabyte of RAM, and a Linux-based operating system. But obviously those sort of specs are unnecessary for an old school POTS desktop phone. Well, that’s what we thought. Then [Josh Max] wrote in to tell us about his adventures in hacking the CaptionCall, and now we’re eager to see what the community can do with root access on a surprisingly powerful Linux phone.
As the names implies, the CaptionCall is a desk phone with an LCD above the keypad that shows real-time captions. Anyone in the United States with hearing loss can get one of these phones for free from the government, so naturally they sell for peanuts on the second hand market. Well, at least they did. Then [Josh] had to go ahead and crack the root password for the ARMv7 i.MX6 powered phone, started poking around inside of its 4 GB of onboard NAND, and got the thing running DOOM.
Tapping into the serial port.
If you’re interested in the technical details, [Josh] has done a great job taking us step by step through his process. It’s a story that will be at least somewhat familiar to anyone who’s played around with embedded Linux devices, and unsurprisingly, starts with locating a serial port header on the PCB.
Finding the environment variables to pretty tightly locked down, he took the slow-route and dumped the phone’s firmware 80 characters at a time with U-Boot’s “memory display” command. Passing the recovered firmware image through binwalk and a password cracker got him the root credentials in short order, and from there, that serial port got a whole lot more useful.
[Josh] kicked the phone’s original UI to the curb, set up an ARM Debian Jessie chroot, and started working his way towards a fully functional Linux environment. With audio, video, and even keypad support secured, he was ready to boot up everyone’s favorite 1993 shooter. He’s been kind enough to share his work in a GitHub repository, and while it might not be a turn-key experience, all the pieces are here to fully bend the hardware to your will.
Historically, running DOOM on a new piece of hardware has been the harbinger of bigger and better things to come. With unfettered access to its Linux operating system up for grabs, we predict the CaptionCall is going to become a popular hacking target going forward, and we can’t wait to see it.
Tamagotchi’s relatively simple technical complexity pales in comparison to its huge cultural impact, with over 76 million sold. It has spawned comics, stories, numerous toys, and offshoots such as an anime and two films. [JC] was looking through some of his old stuff and came across a Tamagotchi P1 (the original Tamagotchi) and decided to create a portable emulator for it. The ROM for the P1 has long been dumped and can be run within a MAME emulator. After all, it’s just a 32MHZ E0C6S46 Epson MCU, 32×16 LCD with 8 additional icons, three buttons, and a piezo. The manual for the MCU is even available on Epson’s website. Here at Hackaday, we’ve seen Tamagotchis many times before, such as the infinite matrix of the Tamagotchi Singularity and a ROM dump of the latest generation of Tamagotchi based on a 6502 core.
So what’s different about what [JC] is trying to accomplish? For starters, the tooling. It is divided into two parts: TamaLIB and TamaTool. The first is a hardware-agnostic P1 emulation library that relies on a HAL layer to communicate with the hardware. The second is a frontend for the first, allowing debugging, RAM editing, and modifications to the ROM. In particular, it supports easy modification of images within the ROM and allows for custom eggs and Tamagotchis. The homage to the Jolly Wrencher is nice.
Given that the emulation is platform-agnostic and access to a low-resolution timer is not guaranteed, cycle counts become tricky. The rather clever solution [JC] stumbled upon was synchronizing against input polling, screen updates, and sound output. TamaLIb keeps track of how many CPU cycles have passed and regularly checks if the emulation is going too fast or too slow. Slowing down or speeding up the simulation allows it to seem to run in real-time.
The last goal [JC] had was to run it on embedded hardware. Using an STM32F072 board and a cheap OLED screen had a portable emulated Tamagotchi known as MCUGotchi. The code is available on GitHub and should work on most STM32 MCUs with a few small tweaks. Now that someone has gone through the effort to make it easy to run a Tamagotchi literally anywhere, it might not be long until we see a coffee maker or a smart light acting as a Tamagotchi. Perhaps the new joke will be, can it run Tamagotchi?
