Although BASIC was most commonly used on home computers like the Commodore VIC-20, it was possible to write programs in other languages, such as Forth. Conveniently, all it took to set up a Forth development system was inserting the cartridge into the VIC-20 and powering it on, with the VIC-FORTH cartridge by [Tom Zimmer] being a popular choice for the Commodore VIC-20. In a recent video, the [My Developer Thoughts] YouTube channel covers Forth development using this cartridge.
In addition to the video tutorial, the original VIC-FORTH Instruction Manual is also available, together with the 1541 disk image. In an upcoming video, the Commodore 64 version of the cartridge will also be covered, which is called 64Forth, and which is also readily available to tinker with. For those interested in learning more about [Tom Zimmer] and his Forth-related work, a 2010 interview could be interesting. This covers the other platforms which he developed an implementation for.
As for why Forth might be interesting to developers and users, this comes mostly down to the much lower overhead of Forth compared to BASIC, while avoiding the pitfalls of ASM and resource-intensive nature of developing in C, as the entire Forth development system (compiler, editor, etc.) comfortably fits in the limited memory of the average 8-bit home computer.
(Thanks to [Stephen Walters] for the tip)
Continue reading “Learn Forth On The Commodore VIC-20”
[Max Woolf] has been working in the AI space since 2015, and among other work has created numerous useful open-source tools. He also recently wrote a thoughtful blog post that attempts to put into words his feelings on the state of things in the wake of experiencing a bit of an AI backlash-related burnout. Essentially, people effortlessly creating vast amounts of bad AI content has caused a bigger problem than we may realize.
How so? Well, Sturgeon’s law (summarized as “ninety percent of everything is crud”) applies to AI as much as it does to anything else. Theodore Sturgeon was a science fiction author and critic (and writer of multiple Star Trek episodes) who observed in the 1950s that while Science Fiction — the hot new popular thing at the time — was often derided by critics as being little more than low quality pap, so was everything else. It was true that most Science Fiction was garbage. But most work in other fields was of similarly low quality, and thus Science Fiction was really no different. It’s all trash, except for the parts one likes. Just like anything else.
What makes this observation particularly applicable to the current AI landscape is that, according to [Max], the incredible ease of use makes AI’s “ninety percent crud” very large indeed, and the attached backlash is similarly big. The remaining ten percent of AI that is absolutely fantastic and full of possibilities? It’s practically invisible due to how quickly the industry is moving, the speed with which the big players are vying to control it, and how unfashionable it has become to admit one is using AI tools at all.
[Max] knows the scene better than most. One of his projects is simpleaichat, a tool aimed not just at enabling people to integrate AI into projects easier, but piercing the hype around AI to more easily reveal just how these tools actually work. Sadly, a general AI backlash has made developing these tools feel rather less rewarding than it once did.
Aside from apparently having both the ability to reproduce on their own and simultaneously never being around when you need one, USB chargers seem innocuous enough. The specs are simple: convert mains voltage to 5 volts, and don’t kill anyone while doing it. Both specs are typically met by most designs, but judging by [DiodeGoneWild]’s latest USB charger teardown, the latter only just barely, and with a whole lot of luck.
The sad state of plug-in USB power supplies is one of [DiodeGoneWild]’s pet gripes, and deservedly so. Most USB chargers cram a lot of electronics into a mighty small volume, and are built to a price point, meaning that something has to give in the design. In the case of the two units he tears apart in the video below, it’s pretty clear where the compromises are. Neither unit met the specs on the label in terms of current supplied and voltage regulation, even the apparently more capable quick charger, which is the first to go under the knife. The PCB within holds some alarming surprises, like the minimal physical isolation between the mains part of the circuit and the low-voltage section, but the real treat is the Schottky diode that gets up to 170°C under full load. Safety tip: when you smell plastic burning, throw the thing out.
The second charger didn’t fare any better; although it didn’t overheat, that’s mainly because it shut itself off before it could deliver a fraction of its rated 1 amp output. The PCB construction was shoddy in the extreme, with a squiggly trace standing in for a proper fuse and a fraction of a millimeter separation between primary and secondary traces. The flyback transformer was a treat, too; who doesn’t want to rely on a whisper-thin layer of cheap lacquer to keep mains voltage out of your phone?
All in all, these designs are horrible, and we have to thank [DiodeGoneWild] for the nightmares we’ll have whenever we plug into one of these things from now on. On the other hand, this was a great introduction to switch-mode power supply designs, and what not to do with our own builds. Continue reading “Just How Dodgy Are Cheap USB Chargers Anyway?”
Those shrunken-down arcade cabinets are a nifty idea, but they sure do suck in practice. At least, the Dance Dance Revolution game is full of empty promises. With the $25 cabinet, all you get are three songs that come out of a crappy little speaker, and a not-great display to match.
[BigRig Creates] endeavored to make it better, however, and managed to cram a Raspberry Pi 4 in the cabinet without disturbing the stock components too much. They did have to trim every extraneous piece of plastic from the inside of the cabinet and trim the I/O pins down, but it fit.
What didn’t fit are the fans that [BigRig Creates] needed once it was clear that it was necessary to overclock the Pi. As [BigRig Creates] points out, a custom PCB would have saved some room. And perhaps time. And definitely some wires.
Unfortunately, it wasn’t that simple on the software side. (It never is, is it?) Even getting the screen to work was no picnic. But in the end, it worked, and even survived a bunch of gamers testing it out at LTX. Check it out after the break.
Got an old PS2 DDR controller? You could make it play Simon instead.
Continue reading “Mini DDR Cabinet Gets Maximum Upgrade”
Controversial position: the world needs more buttons. We’ve gotten so far away from physical interfaces like buttons, knobs, and switches in favor of sleek but sterile touch-screen “controls” that when we see something like this big red button so toddlers can start a TV show, we just have to latch onto the story and see what it’s all about.
As it turns out, the big red button itself is probably the least interesting part of [Mads Chr. Olesen] build. The real meat of the project is the reverse engineering effort needed to get Chromecast to start the show. As [Mads] explains, once upon a time a simple
GET request to a URL was all it took to do so, but no more; Google has repeatedly nerfed the Chromecast API over the years, enough that [Mads] had some digging to do.
Luckily, pyChromecast is a thing, but using it for DRTV, a streaming service of the Danish Broadcasting Corporation, required figuring out the AppID of the DRTV app. It looks like [Mads] used Wireshark to sniff traffic to and from the Chromecast, and netlog-viewer to analyze the capture. That and a little Developer Tools action in Chrome led to all the information needed to modify pyChromecast to support DRTV. The rest of the project consisted of building a box for the huge red arcade button and wiring it up to a Wemos D1. A Raspberry Pi actually talks to the Chromecast, and now the toddler is able to call up his favorite show and pause and restart it at will, no parent required.
We appreciate the reverse engineering heroics [Mads] displays here, which provide good general lessons for other purposes. It’s been a while since we’ve seen a Chromecast physical interface build, too, so we appreciate the refresher.
We’ve talked a few times here about the issues with the CVSS system. We’ve seen CVE farming, where a moderate issue, or even a non-issue, gets assigned a ridiculously high CVSS score. There are times a minor problem in a library is a major problem in certain use cases, and not an issue at all in others. And with some of those issues in mind, let’s take a look at the fourth version of the Common Vulnerability Scoring System.
One of the first tweaks to cover is the de-emphasis of the base score. Version 3.1 did have optional metrics that were intended to temper the base score, but this revision has beefed that idea up with Threat Metrics, Environmental Metrics, and Supplemental Metrics. These are an attempt to measure how likely it is that an exploit will actually be used. The various combinations have been given names. Where CVSS-B is just the base metric, CVSS-BT is the base and threat scores together. CVSS-BE is the mix of base and environmental metrics, and CVSS-BTE is the combination of all three.
Another new feature is multiple scores for a given vulnerability. A problem in a library is first considered in a worst-case scenario, and the initial base score is published with those caveats made clear. And then for each downstream program that uses that library, a new base score should be calculated to reflect the reality of that case. Continue reading “This Week In Security: CVSS 4, OAuth, And ActiveMQ”
If you are a ham radio operator of a certain age, you probably remember ads for “The Instructograph,” a mechanical device for learning Morse code. [Our Own Devices] has an ancient specimen of the machine and shows us how it works in the video below. The machine is a model of simplicity. You wind up a spring-driven motor like you would for an old record player or music box. A slider sets the playback rate, and paper tape starts to spin.
The paper tape looks like computer tape, but since it only has literal long and short notches, it has two distinct sides. When you learned one set of messages, you could flip the tape over and get more practice that way. How did the machine read the paper tape? With a mechanical contact. Literally, if the paper had a hole in it, you made the circuit. If it didn’t, the circuit was broken. A buzzer and batteries or some other kind of sounder was all you needed.
The company was in business for 50 years. The newer versions had more electronics, but they always used the paper tape mechanism to store the code practice sessions. A 1962 ad noted that the machine could play back the tapes from three words a minute up to 40. You could buy or rent the machine, and we always assumed it was pretty pricey for its day. Around 1965, a new unit would cost $53 but did not include a headset or a key. So that was actually more reasonable than we expected. In 1965, a brand-name clock radio cost about $50, so it wasn’t any more than that.
Everyone has their own favorite method for learning code, especially [Ludwig Koch]. At least you don’t have to learn Alex-style.
Continue reading “Machine Teaches Morse Code”