Today in old school nostalgia our tipster [Clint Jay] wrote in to let us know about this rotary dial.
If you’re a young whippersnapper you might never have seen a rotary dial. These things were commonly used on telephones back in the day, and they were notoriously slow to use. The way they work is that they generate a number of pulses corresponding to the number you want to dial in. One pulse for 1, two pulses for 2, and so on, up to nine pulses for 9, then ten pulses for 0.
One thing that makes this particular project different from the ones we’ve seen before is that it doesn’t require a microcontroller. That said, our hacker [Mousa] shows us how to interface this dial with an Arduino, along with sample code, if that’s something you’d like to do. The schematic for the project shows how to connect the rotary dial (salvaged from an old telephone) to both a 7-segment display and a collection of ten LEDs.
The project write-up includes links to the PCB design files. The guts of the project are a 4017 decade counter and a 4026 7-segment display adapter. Good, honest, old school digital logic.
The build is based around a central core, which combines the pickups, bridge, and neck into one solid unit. This is really the heart of the guitar, containing all the pieces that need to be in precise alignment to get those strings vibrating precisely in tune. The core then mounts to a printed outer body via mating slots and rails, which in the main demo is made to look like a Les Paul-style design. This outer body also hosts the volume, tone, and pickup controls. Output from the pickups travels to the controls in the outer body via a set of metallic contacts.
What’s cool about this build is that the sky really is the limit for your creativity. As the video below demonstrates, the main build looks like a Les Paul. But, armed with the right CAD software, you can really make a guitar that looks like whatever you want, while the 3D printer does all the hard work of making it a reality. The files to print the guitar, along with the pickups and other components, are available as kits—but there’s also nothing stopping you from working up your own printed guitar design from scratch, either.
Adding textures is a great way to experiment with giving 3D prints a different look, and [PandaN] shows off a method of adding a wood grain effect in a way that’s easy to play around with. It involves using a 3D model of a log (complete with concentric tree rings) as a print modifier. The good news is that [PandaN] has already done the work of creating one, as well as showing how to use it.
The model of the stump — complete with concentric tree rings — acts as a modifier for the much-smaller printed object (in this case, a small plate).
In the slicer software one simply uses the log as a modifier for an object to be printed. When a 3D model is used as a modifier in this way, it means different print settings get applied everywhere the object to be printed and the modifier intersect one another.
In the case of this project, the modifier shifts the angle of the fill pattern wherever the models intersect. A fuzzy skin modifier is used as well, and the result is enough to give a wood grain appearance to the printed object. When printed with a wood filament (which is PLA mixed with wood particles), the result looks especially good.
In addition to the 3D models, [PandaN] provides a ready-to-go project for Bambu slicer with all the necessary settings already configured, so experimenting can be as simple as swapping the object to be printed with a new 3D model. Want to see that in action? Here’s a separate video demonstrating exactly that step-by-step, embedded below.
To some, an operating system is a burden or waste of resources, like those working on embedded systems and other low-power applications. To others it’s necessary, abstracting away hardware so that higher-level programming can be done. For most people it’s perhaps not thought of at all. But for a few, the operating system is the most interesting piece of software running on a computer and if you’d like to investigate what makes this often overlooked aspect of computer science interesting, take a look at this course on operating systems from Cornell University.
The operating system itself is called Earth and Grass Operating System because it splits the functionality of the operating system into three separate parts. The Earth layer involves dealing with hardware, the Grass layer involves hardware-independent aspects, and a third application layer implements other key operating system features. It’s built for a RISC-V processor, since that instruction set is completely open source and transparent about what it’s doing. It’s also incredibly small, coming in at around 2000 lines of code. The course covers nine areas, with the first six being core operating system functions and the remaining three covering more advanced operating system concepts.
For understanding the intricacies and sometimes mysterious ways that operating systems work, a course like this can go a long way into unraveling those mysteries and developing a deeper understanding of how it brings the hardware to work for higher-level software. We actually featured this operating system two years ago, before this course was created, which covers this project for those who like to take a more self-directed approach, or simply want a lightweight OS for a RISC-V system.
While LEGO themed video games have become something of a staple, in 1997 they were something of an odity. LEGO Island became the first LEGO video game released outside of Japan in 1997 and become something of a hit with over one million copies sold. The game was beloved among fans and set the stage for more LEGO video games to come. In an effort of love, [MattKC] put together a team to reverse engineer the game.
The team set out with the intent to create a near perfect recreation of the codebase, relying on custom made tools to run byte checks on the rewrite compilation and the original binary. While the project is functionally complete, [MattKC] believes it is impossible to get a byte accurate codebase. This is because of what the team called “compiler entropy.” Strange behaviors exists inside of Microsoft’s Visual C++ compiler of the era, and small changes in the code have seemingly random effects to unrelated parts of the binary. To mitigate this issue would likely require either partially reverse engineering Visual C++ or brute forcing the code, both of which would take a large amount of effort and time for no real benefit.
Another interesting step the team had to work out was how the game handled graphics. In the version of Direct X used, the developers could chose between immediate mode and retained mode. The difference largely boils down to how models and assets are handled. In immediate mode, Direct X is largely just a render engine and everything else is handled by the developer. With retained mode, Direct X works more similarly to a game engine where all the model and asset management is handled by Direct X. Almost all developers ended up using immediate mode to the point that Microsoft deprecated support for retained mode. For this reason, if you were to download and run LEGO island on a modern Windows PC, it would yell at you for not having the proper libraries. There is debate about how best to handle this moving forward. The team could rely on an unsupported library from Microsoft, reverse engineer that library only making the functions needed, or using leaked source code.
With the completion of the reverse engineering, engineering can commence. For example, an annoying and persistent bug caused the game to crash if you tried to exit. While it was effective in closing the game, it also caused progress to be lost. That particular bug was fixed simply by initializing a variable in the game’s fronted. Interestingly, that bug was not present in the late betas of the game that had been dug up from the depths of the internet leading to questions as to why a rewrite of the fronted was necessary so late in the development. Now efforts are commencing to port the game to other platforms which bring with it fresh headaches including rewriting for OpenGL and the balance of keeping a historically accurate game with the needs of modern development.
For our cow, we need a stage/barn with a feeding station and water trough, each of which displays different levels.
The cow should
stand, smile, chew, look sad
eat, drink
lying down ruminating , smile, sleep
These images are stored as code on an extra file named “cow-all.h” and loaded when needed.
The images are self made, you are free to use them.
Step 2: The Cow Software
The CYD is a fantastic combination of ESP32 and Touchschreeen. It saves you the annoying soldering and cables.
My programming is admittedly a bit amateurish. You can certainly get more out of the CYD in terms of design or give the cow more functions. But at least the program steps are easy to follow.
The library can be used to simulate a wide variety of working surfaces. We don’t show a background, but concentrate on the cow, watering place and feeding place. Three click areas are integrated in a hidden manner, i.e. they are not visible but can be clicked in three places: Water and feed place for refilling and the cow itself for stroking.
The cow’s status is (soon) saved on the ESP32 so that the device can be switched off at any time and you keep the food/mood status.
The values of hunger and thirst change randomly. The ESP32 counts the milliseconds. These values can be set according to your personal preferences.
The file “cow-all.h” contains all the different cow images in code and must be stored in the same folder as “demo.ino” or “tamagotchi_cow.ino”!
Attachments
Step 3: Speaker and LDR Sensor
The speaker for ‘Mooh’ is optional. Unfortunately, I have not yet been able to get the sound function to work without complications with the screen. Every time the SD card is online the touchscreen is not working properly. Any idea?
The mp3 file(s) could be saved on the SD card. The connection pins are on the back of the CYD. I got the speaker from an old fixed line telephone.
The built-in LDR sensor (GPIO 34) tells the cow when to sleep. When it is dark, she lies down. During this time, water and food are not consumed.
Attachments
Step 4: The Barn
For the ambience, I quickly designed a stable with tinkercad.com and turned it into reality with the 3D printer. Of course, you can also build a wonderful miniature stable out of wood here. Don’t forget good ventilation at the back side.
The cow eats and drinks when its internal water and feed levels drop (= hunger, thirst). If the water or feed container is empty, the cow is hungry, unhappy and mooing.
If you tap on water or feed, the supplies are replenished and the cow can eat. If you tap on the cow (= stroking), it is also happy and moos comfortably.
When the LDR notices darkness the cow is going to sleep. She does not eat and does not develop much hunger or thirst.
