Does This Demo Remind You of Mario Kart? It Should!

Here’s a slick-looking VGA demo written in assembly by [Yianni Kostaris]; it’s VGA output from an otherwise stock ATmega2560 at 16MHz with no external chips involved. If you’re getting some Super Mario Kart vibes from how it looks, there’s a good reason for that. The demo implements a form of the Super Nintendo’s Mode 7 graphics, which allowed for a background to be efficiently texture-mapped, rotated, and scaled for a 3D effect. It was used in racing games (such as Super Mario Kart) but also in many others. A video of the demo is embedded below.

[Yianni] posted the original demo a year earlier, but just recently added detailed technical information on how it was all accomplished. The AVR outputs VGA signals directly, resulting in 100×120 resolution with 256 colors, zipping along at 60 fps. The AVR itself is not modified or overclocked in any way — it runs at an entirely normal 16MHz and spends 93% of its time handling interrupts. Despite sharing details for how this is done, [Yianni] hasn’t released any code, but told us this demo is an offshoot from another project that is still in progress. It’s worth staying tuned because it’s clear [Yianni] knows his stuff.

Continue reading “Does This Demo Remind You of Mario Kart? It Should!”

LTSpice for Radio Amateurs (and Others)

We don’t think [VK4FFAB] did himself a favor by calling his seven-part LTSpice tutorial LTSpice for Radio Amateurs. Sure, the posts do focus on radio frequency analysis, but these days lots of people are involved in radio work that aren’t necessarily hams.

Either way, if you are interested in simulating RF amplifiers and filters, you ought to check these posts out. Of course, the first few cover simple things like voltage dividers just to get your feet wet. The final part even covers a double-balanced mixer with some transformers, so there’s quite a range of material.

Continue reading “LTSpice for Radio Amateurs (and Others)”

Sticking With The Script For Cheap Plane Tickets

When [Zeke Gabrielse] needed to book a flight, the Internet hive-mind recommended that he look into traveling with Southwest airlines due to a drop in fares late Thursday nights. Not one to stay up all night refreshing the web page indefinitely, he opted to write a script to take care of the tedium for him.

Settling on Node.js as his web scraper of choice, numerous avenues of getting the flight pricing failed before he finally had to cobble together a script that would fill out and submit the search form for him. With the numbers coming in, [Grabrielse] set up a Twilio account to text him  once fares dropped below a certain price point — because, again, why not automate?

Continue reading “Sticking With The Script For Cheap Plane Tickets”

Build Your Own P-Brain

I don’t think we’ll call virtual assistants done until we can say, “Make me a sandwich” (without adding “sudo”) and have a sandwich made and delivered to us while sitting in front of our televisions. However, they are not completely without use as they are currently – they can let you know the time, weather and traffic, schedule or remind you of meetings and they can also be used to order things from Amazon. [Pat AI] was interested in building an open source, extensible, virtual assistant, so he built P-Brain.

Think of P-Brain as the base for a more complex virtual assistant. It is designed from the beginning to have more skills added on in order to grow its complexity, the number of things it can do. P-Brain is written in Node.js and using a Node package called Natural, P-Brain parses your request and matches it to a ‘skill.’ At the moment, P-Brain can get the time, date and weather, it can get facts from the internet, find and play music and can flip a virtual coin for you. Currently, P-Brain only runs in Chrome, but [Pat AI] has plans to remove that as a dependency. After the break, [Pat AI] goes into some detail about P-Brain and shows off its capabilities. In an upcoming video, [Pat AI]’s going to go over more details about how to add new skills. Continue reading “Build Your Own P-Brain”

Optimizing Linux for Slow Computers

It’s interesting, to consider what constitutes a power user of an operating system. For most people in the wider world a power user is someone who knows their way around Windows and Microsoft Office a lot, and can help them get their print jobs to come out right. For those of us in our community, and in particular Linux users though it’s a more difficult thing to nail down. If you’re a LibreOffice power user like your Windows counterpart, you’ve only really scratched the surface. Even if you’ve made your Raspberry Pi do all sorts of tricks in Python from the command line, or spent a career shepherding websites onto virtual Linux machines loaded with Apache and MySQL, are you then a power user compared to the person who knows their way around the system at the lower level and has an understanding of the kernel? Probably not. It’s like climbing a mountain with false summits, there are so many layers to power usership.

So while some of you readers will be au fait with your OS at its very lowest level, most of us will be somewhere intermediate. We’ll know our way around our OS in terms of the things we do with it, and while those things might be quite advanced we’ll rely on our distribution packager to take care of the vast majority of the hard work.

Linux distributions, at least the general purpose ones, have to be all things to all people. Which means that the way they work has to deliver acceptable performance to multiple use cases, from servers through desktops, portable, and even mobile devices. Those low-level power users we mentioned earlier can tweak their systems to release any extra performance, but the rest of us? We just have to put up with it.

To help us, [Fabio Akita] has written an excellent piece on optimizing Linux for slow computers. By which he means optimising Linux for desktop use on yesterday’s laptop that came with Windows XP or Vista, rather than on that ancient 486 in the cupboard. To a Hackaday scribe using a Core 2 Duo, and no doubt to many of you too, it’s an interesting read.

In it he explains the problem as more one of responsiveness than of hardware performance, and investigates the ways in which a typical distro can take away your resources without your realising it. He looks at RAM versus swap memory, schedulers, and tackles the thorny question of window managers head-on. Some of the tweaks that deliver the most are the easiest, for example the Great Suspender plugin for Chrome, or making Dropbox less of a hog. It’s not a hardware hack by any means, but we suspect that many readers will come away from it with a faster machine.

If you’re a power user whose skills are so advanced you have no need for such things as [Fabio]’s piece, share your wisdom on sharpening up a Linux distro for the rest of us in the comments.

Via Hacker News.

Header image, Tux: Larry Ewing, Simon Budig, Garrett LeSage [Copyrighted free use or CC0], via Wikimedia Commons.

Documentation by Markup

Things seem to go in cycles. Writing a document using old-fashioned tools like TROFF or LaTeX is like knowing a secret code. Visual editors quickly took over, although even WordStar had some “dot commands” that you put in as text. Then HTML showed up and we were back to coding formatting as text strings.

Fast forward to the present, and HTML’s ubiquity makes that seem normal. Sure, there are visual editors, but it seems perfectly normal now to write <b> for bold text. However, as HTML grows to handle more tasks it also gets more complex. That’s led to the creation of things like Markdown which is just for simple text formatting. Continue reading “Documentation by Markup”

TruffleHog Sniffs Github for Secret Keys

Secret keys are quite literally the key to security in software development. If a malicious actor gains access to the keys securing your data, you’re toast. The problem is, to use keys, you’ve got to write them down somewhere – oftentimes in the source code itself. TruffleHog has come along to sniff out those secret keys in your Github repository.

It’s an ingenious trick — a Python script goes through the commit history of a repository, looking at every string of text greater than 20 characters, and analyzing its Shannon entropy. This is a mathematical way of determining if it looks like a relatively random string of numbers and letters. If it has high entropy, it’s probably a key of some sort.

Sharing source code is always a double-edged sword for security. Any flaws are out for all to see, and there are both those who will exploit the flaws and those who will help fix them. It’s a matter of opinion if the benefits outweigh the gains, but it’s hard to argue with the labor benefits of getting more eyes on the code to hunt for bugs. It’s our guess though, that a lot of readers have accidentally committed secret keys in a git repository and had to revert before pushing. This tool can crawl any publicly posted git repo, but might be just as useful in security audits of your own codebase to ensure accidentally viewable keys are invalidated and replaced.

For a real world example of stolen secret keys, read up on this HDMI breakout that sniffs HDCP keys.