Emulating a 6502 shouldn’t be that hard on a modern computer. Maybe that’s why [lasect] decided to make it a bit harder. The PG_6502 emulator uses PostgreSQL. All the CPU resources are database tables, and all opcodes are stored procedures. Huh.
The database is pretty simple. The pg6502.cpu table has a single row that holds the registers. Then there is a pg6502.mem table that has 64K rows, each representing a byte. There’s also a pg6502.opcode_table that stores information about each instruction. For example, the 0xA9 opcode is an immediate LDA and requires two bytes.
The pg6502.op_lda procedure grabs that information and updates the tables appropriately. In particular, it will load the next byte, increment the program counter, set the accumulator, and update the flags.
Honestly, we’ve wondered why more people don’t use databases instead of the file system for structured data but, for us, this may be a bit much. Still, it is undoubtedly unique, and if you read SQL, you have to admit the logic is quite clear.
Usually databases are treated primarily as fairly dumb data storage systems, but they can be capable of much more. Case in point the PostgreSQL database and its – Ada-based – PL/pgSQL programming language, which allows you to perform significantly more complex operations than would be realistically possible with raw SQL. Case in point the implementation of a Kalman Filter by the folk over at Traconiq, which thus removes the necessity for an external filtering pipeline.
Using a Kalman Filter is highly desirable when you’re doing something like vehicle tracking using both dead-reckoning and GPS coordinates, as it filters out noise that can be the result of e.g. GPS reception issues. As noted in the article, transferring state from one row to the next requires a bit of lateral thinking, but is doable with some creative SQL usage. As PL/pgSQL is very similar to Oracle’s PL/SQL, this same code should work there too without too much porting required.
The code for the different implementations and associated benchmarks can be found on GitHub, though the benchmark results make it abundantly clear that the most efficient approach is to run an offline aggregate processing routine. This coincides with the other batch processing tasks that are typically performed by a database server to e.g. optimize storage, so this isn’t entirely unsurprising.
These days you can run Doom anywhere on just about anything, with things like porting Doom to JavaScript these days about as interesting as writing Snake in BASIC on one’s graphical calculator. In a twist, [Patrick Trainer] had the idea to use SQL instead of JS to do the heavy lifting of the Doom game loop. Backed by the Web ASM version of the analytical DuckDB database software, a Doom-lite clone was coded that demonstrates the principle that anything in life can be captured in a spreadsheet or database application.
Rather than having the game world state implemented in JavaScript objects, or pixels drawn to a Canvas/WebGL surface, this implementation models the entire world state in the database. To render the player’s view, the SQL VIEW feature is used to perform raytracing (in SQL, of course). Any events are defined as SQL statements, including movement. Bullets hitting a wall or impacting an enemy result in the bullet and possibly the enemy getting DELETE-ed.
The role of JavaScript in this Doom clone is reduced to gluing the chunks of SQL together and handling sprite Z-buffer checks as well as keyboard input. The result is a glorious ASCII-based game of Doom which you can experience yourself with the DuckDB-Doom project on GitHub. While not very practical, it was absolutely educational, showing that not only is it fun to make domain specific languages do things they were never designed for, but you also get to learn a lot about it along the way.
Who’d have thought that $30 doorbell cameras would end up being security liabilities? That’s the somewhat obvious conclusion reached by Consumer Reports after looking at some entry-level doorbell cameras available through the usual outfits and finding glaring security gaps which are totally not intentional in any way.
All these cameras appear to be the same basic hardware inside different enclosures, most supporting the same mobile app. Our favorite “exploit” for these cameras is the ability to put them into a pairing mode with the app, sometimes by pressing a public-facing button. Slightly more technically challenging would be accessing images from the app using the camera’s serial number, or finding file names being passed in plain text while sniffing network traffic. And that’s just the problems CR identified; who knows what else lurks under the covers? Some retailers have stopped offering these things, others have yet to, so buyer beware.
Speaking of our techno-dystopian surveillance state, if you’ve had it with the frustrations and expense of printers, has Hewlett-Packard got a deal for you. They want you to never own a printer again, preferring that you rent it from them instead. Their “All-In Plan” launched this week, which for $6.99 a month will set up up with an HP Envy inkjet printer, ink deliveries, and 24/7 tech support. It doesn’t appear that paper is included in the deal, so you’re on your own for that, but fear not — you won’t go through much since the entry-level plan only allows 20 prints per month. Plans scale up to 700 prints per month from an OfficeJet Pro for the low, low price of $36. The kicker, of course, is that your their printer has to be connected to the Internet, and HP can pretty much brick the thing anytime they want to. The terms of service also explicitly state that they’ll be sending your information to advertising partners, so that’ll be fun. This scheme hearkens back to the old pre-breakup days of AT&T, where you rented your phone from the phone company. That model made a lot more sense when the phone (probably) wasn’t listening in on everything you do. This just seems like asking for trouble.
It’s been a while since Ingenuity‘s final rough landing on Mars permanently grounded the overachieving helicopter, long enough that it’s time for the post-mortem analyses to begin. The first photographic evidence we had was a shadowgram from one of the helicopter’s navigational cameras, showing damage to at least one of the rotor tips, presumably from contact with the ground. Then we were treated to a long-distance shot from Ingenuity‘s rover buddy Perseverance, which trained its MASTCAM instruments on the crash zone and gave us a wide view of its lonely resting place.
Now, geovisual design student [Simeon Schmauβ] has taken long shots made with the rover’s SuperCam instrument and processed them into amazingly detailed closeups, which show just how extensive the damage really is. One rotor blade sheared clean off on contact, flying 15 meters before gouging a hole in the regolith. Another blade looks to be about half gone, while the remaining two blades show the damaged tips we’ve already seen. That the helicopter is still on its feet given the obvious violence of the crash is amazing, as well as an incredible piece of luck, since it means the craft’s solar panel is pointing in roughly the right direction to keep it powered up.
Although modern Linux has slightly shifted, the old Unix mantra was: everything’s a file. With Steampipe, a better saying might be: everything’s a SQL table. The official tagline is “select * from cloud” which also works. The open-source program relies on plugins, and there are currently 140 sources ranging from GitHub to Google Sheets and more.
[P B Richards] and [Aaron Flin] were bemoaning the resource hunger of modern JavaScript environments and planned to produce a system that was much stingier with memory and CPU, that would fit better on lower-end platforms. Think Nginx, NodeJS, and your flavour of database and how much resource that all needs to run properly. Now try wedge that lot onto a Raspberry Pi Zero. Well, they did, creating Rampart: a JavaScript-based complete stack development environment.
The usual web applications have lots of tricks to optimise for speed, but according to the developers, Rampart is still pretty fast. Its reason for existence is purely about resource usage, and looking at a screen grab, the Rampart HTTP server weighs in at less than 10 MB of RAM. It appears to support a decent slew of technologies, such as HTTPS, WebSockets, SQL search, REDIS, as well as various utility and OS functions, so shouldn’t be so lightweight as to make developing non-trivial applications too much work. One interesting point they make is that in making Rampart so frugal when deployed onto modern server farms it could be rather efficient. Anyway, it may be worth a look if you have a reasonable application to wedge onto a small platform.
We’ve seen many JavaScript runtimes over the years, like this recent effort, but there’s always room for one more.
At Hackaday, we love things both from scratch and in Scratch, Scratch being the blocks building helpful language for teaching kids and the like how to program. However, when you have a large amount of data that needs to be processed, queried, and collated to get meaningful insights, it is a pain to rewrite a SQL query every time a new question arises that needs an answer. So perhaps a more elegant approach would be to give the people asking the questions the tools to answer them, but rather than teach them SQL, Mongo, GraphQL, or any other database, give them the tools to scratch out the answers themselves.
That’s enough scratch puns for one article. [Tommy] ran into this situation in 2011 and recently wrote about it. Scratch came out in 2003 and has inspired several projects, such as Google’s Blockly. [Tommy] used Blockly to create a web app where users could drag and drop different blocks to form queries. These layouts were passed to a PHP-backed (though later HVVM for performance reasons) and executed as SQL.
Eventually, big data came around, and the company hired proper data scientists. Though [Tommy] notes that some of those who used his tool went on to learn proper SQL and do it themselves. Applying concepts from programs designed to teach children programming might sound a little odd in a business sense, but we love seeing projects that help someone become curious enough to peer inside the machine.
