Robot Pet Is A Chip Off The Old Logic Block

August 15, 2021 by Ryan Flowers 10 Comments

When [Ezra Thomas] needed inspiration for his senior design project, he only needed to look as far as his own robot. Built during his high school years from the classic 1979 Frank DaCosta book “How to Build Your Own Working Robot Pet”, [Ezra] had learned the hard way the many limitations and complexities of the wire wrapped 74xx series logic chips surrounding its 8085 processor.

[Ezra] embarked on a quest to recreate the monstrosity in miniature, calling it Pet on a Chip. Using a modern FPGA chip allows the electronics to shrink by an order of magnitude and provides flexibility for future expansion. Implementing an 8 bit CPU on the amply sized FPGA left plenty of room for a VGA GPU, motor controller, serial UART, and more. Programming the CPU is handled by a custom assembler written in Python.

The results? Twelve times less weight, thirteen times less power draw, better performance, and a lot of room for growth. [Ezra] hints at an I2C bus expansion as well as a higher level programming language to make software development less of a hurdle.

The Pet On A Chip is a wonderfully engineered project and we hope that we’ll be seeing more such from [Ezra] as time goes by. Watch his Pet On A Chip in action in the video below the break.

If [Ezra]’s FPGA escapades have you wondering how to get started, you can check out this introduction to FPGA from the 2019 Hackaday Superconference. And if you have your own FPGA creation to share, please let us know via the Tip Line!

Continue reading “Robot Pet Is A Chip Off The Old Logic Block” →

FreeBSD Experiment Rethinks The OS Install

August 10, 2021 by Tom Nardi 31 Comments

While the medium may have evolved from floppy disks to DVDs and USB flash drives, the overall process of installing an operating system onto a desktop computer has been more or less the same since the 1980s. In a broad sense you could say most OS installers require more clicking than typing these days, but on the whole, not a lot has really changed. Of course, that doesn’t mean there isn’t room for improvement.

Among the long list of projects detailed in FreeBSD’s April to June 2021 Status Report is a brief update on an experimental installer developed by [Yang Zhong]. In an effort to make the installation of FreeBSD a bit more user friendly, the new installer does away with the classic terminal interface and fully embraces the modern web-centric design paradigm. Once the user has booted into the live OS, they simply need to point the browser to the loopback address at any time to access the installer’s GUI.

Now that alone wouldn’t be particularly groundbreaking. After all, Google has implemented an entire operating system with web frameworks in Chrome OS, so is making the installer a web app really that much of a stretch? But what makes [Yang]’s installer so interesting is that the web interface isn’t limited to just the local machine, it can be accessed by any browser on the network.

That means you can put the install disc for FreeBSD into a headless machine on your network, and use the browser on your laptop or even smartphone to access the installer. The Graybeards will point out that savvy users have always been able to access the text installer from another computer over SSH, but even the most staunch Luddite has to admit that simply opening a browser on whatever device you have handy and pointing it to the target machine’s IP address is a big usability improvement.

While the software appears complete enough to get through a basic installation, we should remind readers these are still early days. There’s currently no authentication in place, so once you’re booted into the live environment, anyone on the network can format your drives and start the install process.

Some sections of the GUI aren’t fully functional either, with the occasional note from [Yang] popping up to explain what does and doesn’t work. For example, the manual network configuration panel currently only works with WiFi interfaces, as that’s all he personally has to test with. Quite a modern installer, indeed.

Some would argue that part of what makes alternative operating systems like Linux and BSD appealing is the fact that they can happily run on older hardware, so we imagine the idea of an installer using a memory-hungry web browser to present its interface won’t go over well with many users. In our testing, the experimental installer ISO won’t even boot unless it detected at least 4 GB of RAM onboard. But it’s certainly an interesting experiment, and something to keep an eye on as it matures.

[Thanks to Michael for the tip.]

ESP8266 Network Meters Show Off Unique Software

August 10, 2021 by Tom Nardi 15 Comments

Like the “Three Seashells” in Demolition Man, this trio of bright yellow network monitors created by [David Chatting] might be difficult to wrap your head around at first glance. They don’t have any obvious controls, and their constantly moving indicators are abstract to say the least. But once you understand how to read them, and learn about the unique software libraries he’s developed to make them work, we’re willing to bet you’ll want to add something similar to your own network.

First-time configuration of the monitors is accomplished through the Yo-Yo WiFi Manager library. It’s a captive portal system, not unlike the popular WiFiManager library, but in this case it has the ability to push the network configuration out to multiple devices at once. This MIT-licensed library, which [David] has been developing with [Mike Vanis] and [Andy Sheen], should be very helpful for anyone looking to bring multiple sensors online quickly.

We’re also very interested in what [David] calls the Approximate library. This allows an ESP8266 or ESP32 to use WiFi signal strength to determine when its been brought in close proximity to particular device, and from there, determine its IP and MAC address. In this project, it’s used to pair the “Device Wheel” monitor with its intended target.

Once locked on, the monitor’s black and white wheel will spin when it detects traffic from the paired device. We think this library could have some very interesting applications in the home automation space. For example, it would allow a handheld remote to control whatever device the user happens to be closest to at the time.

Whether you follow along with the instructions and duplicate the meters as-is, or simply use the open source libraries that power them in your own project, we think [David] has provided the community with quite a gift in these unique gadgets.

ReactOS Is Going Places, With More Stable AMD64, SMP, And Multi-Monitor Support

August 8, 2021 by Jenny List 54 Comments

In the crowd of GNU/Linux and BSD users that throng our community, it’s easy to forget that those two families are not the only games in the open-source operating system town. One we’ve casually kept an eye on for years is ReactOS, the long-running open-source Windows-compatible operating system that is doing its best to reach a stable Windows XP-like experience. Their most recent update has a few significant advances mentioned in it that hold the promise of it moving from curiosity to contender, so is definitely worth a second look.

ReactOS has had 64-bit builds for a long time now, but it appears they’ve made some strides in both making them a lot more stable, and moving away from the MSVC compiler to GCC. Sadly this doesn’t seem to mean that this now does the job of a 64-bit Windows API, but it should at least take advantage internally of the 64-bit processors. In addition they have updated their support for the Intel APIC that is paving the way for ongoing work on multiprocessor support where their previous APIC driver couldn’t escape the single processor constraint of an original Intel 8259.

Aside from these its new-found support for multiple monitors should delight more productive users, and its improved support for ISA plug-and-play cards will be of interest to retro enthusiasts.

We took a close look at the current ReactOS release when it came out last year, and concluded that its niche lay in becoming a supported and secure replacement for the many legacy Windows XP machines that are still hanging on years after that OS faded away. We look forward to these and other enhancements in their next release, which can’t be far away.

Knowing The Bits And Bytes That Make Images Live In Memory

August 5, 2021 by Mike Szczys 16 Comments

We know we’re living in the future because there’s hi-resolution, full color images plastered on every high-density screen in sight. Of course this comes at a cost, one that’s been hidden away by the myriad improvements in the way we digitally represent those pretty pixels and how we push them to the screens. Nobody thinks about this, except those who are working behind the screen to store and light up those pixels. And hey, chances are that’ll be you some day. Time to learn a bit more about image encoding!

Test renders illustrate the time savings from premultiplied alpha formats

[Scott W Harden] put together a succinct primer on representing images in memory. It focuses on the basics of how images are stored: generally with the B before the G, sometimes including an alpha (transparent) channel, and with a number of different bit depths. Having these at the front of your mind is crucial for microcontroller projects, where deciding what types of images to support is often limited by the amount of memory available for frame buffers, and the capabilities of the screen chosen as the device’s display.

Speaking of display specifics, [Scott] shares some detail about mapping the memory to the dimensions of your screen. If the byte count of pixel data doesn’t line up nicely with the dimensions of the screen, padding the rows out may help in the processing overhead it takes to get those pixels onto the screen. He also has some tips about “premultiplied alpha” which makes the transparency calculation a part of the image itself, rather than demanding this be done when trying to update the screen. Running a test in C# on one million frame renders shows the type of savings you can expect.

Decades of trial and error landed us with these schemes. Looking back is literally an archaeology project, as one hacker discovered when trying to get a set of digital images off of a floppy from a 1990s photo processing service.

GitHub Copilot And The Unfulfilled Promises Of An Artificial Intelligence Future

August 2, 2021 by Maya Posch 36 Comments

In late June of 2021, GitHub launched a ‘technical preview’ of what they termed GitHub Copilot, described as an ‘AI pair programmer which helps you write better code’. Quite predictably, responses to this announcement varied from glee at the glorious arrival of our code-generating AI overlords, to dismay and predictions of doom and gloom as before long companies would be firing software developers en-masse.

As is usually the case with such controversial topics, neither of these extremes are even remotely close to the truth. In fact, the OpenAI Codex machine learning model which underlies GitHub’s Copilot is derived from OpenAI’s GPT-3 natural language model, and features many of the same stumbles and gaffes which GTP-3 has. So if Codex and with it Copilot isn’t everything it’s cracked up to be, what is the big deal, and why show it at all?

Continue reading “GitHub Copilot And The Unfulfilled Promises Of An Artificial Intelligence Future” →

New Privacy Policy Gets Audacity Back On Track

July 23, 2021 by Tom Nardi 29 Comments

Regular readers will likely be aware of the considerable debate over changes being made to the free and open source audio editor Audacity by the project’s new owners, Muse Group. The company says their goal is to modernize the 20 year old GPLv2 program and bring it to a larger audience, but many in the community have questioned whether the new managers really understand the free software ethos. An already precarious situation has only been made worse by a series of PR blunders Muse Group has made over the last several months.

But for a change, it seems things might be moving in the right direction. In a recent post to Audacity’s GitHub repository, Muse Group unveiled the revised version of their much maligned Privacy Policy. The announcement also came with an admission that many of the key elements from the draft version of the Privacy Policy were poorly worded and confusing. It seems much of the problem can be attributed to an over-analysis of the situation; with the company inserting provocative boilerplate protections (such as a clause saying users must be over the age of 13) that simply weren’t necessary.

Ultimately, the new Privacy Policy bears little resemblance to the earlier draft. Which objectively, is a good thing. But it’s still difficult to understand why Muse Group publicly posted such a poorly constructed version of the document in the first place. Project lead Martin Keary, better known online as Tantacrul, says the team had to consult with various legal teams before they could release the revised policy. That sounds reasonable enough, but why where these same teams not consulted before releasing such a spectacularly ill-conceived draft?

The new Privacy Policy makes it clear that Audacity won’t be collecting any user data, and what little personally identifiable information Muse Group gets from the application when it automatically checks for an update (namely, the client’s IP address) isn’t being stored. It’s further explained in the GitHub post that the automatic update feature only applies to official binary builds of Audacity, meaning it will be disabled for Linux users who install it through their distribution’s package repository. The clause about working with unnamed law enforcement agencies has been deleted, as has the particularly troubling age requirement.

Credit where credit is due. Muse Group promised to revise their plans for adding telemetry to Audacity, and judging by the new Privacy Policy, it seems they’ve done an admirable job of addressing all of the issues brought up by the community. Those worried their FOSS audio editor of choice would start spying on them can rest easy. Unfortunately the issue of Audacity’s inflammatory Contributor License Agreement (CLA) has yet to be resolved, meaning recently christened forks of the audio editor dedicated to preserving its GPLv2 lineage are unlikely to stand down anytime soon.