If you ask a normal person to pick a random number, they’ll usually just blurt out a number. But if you ask a math-savvy person for a random number, you’ll probably get a lecture about how hard it is to pick a truly random number. But if you ask [Valerio Nappi], you might just get a banana.
His post, which is in two parts, details how what computers generate are actually pseudo-random numbers. You can easily make sure that every number has the same probability of selection as any other number. The problem is that you have to start with something — usually called a seed. For the purposes of playing games, for example, you can grab some source of entropy like how many microseconds since a hardware timer last rolled over, the number of input pulses you’ve received from a mouse lately, or how long you had to wait for the enter key to depress after asking the user to press it. But if you know that seed and the algorithm you can perfectly predict what number the computer will generate next so it isn’t truly random.
According to [Victor Tangermann] over at Futurism, JetPack Aviation is showing a prototype of its P2 Speeder flying motorcycle and it looks both awesome and — to quote Ralph Nader — unsafe at any speed. The prototype can lift 1,000 pounds, travel at up to 500 miles per hour, and cover up to 400 miles. We assume those things are not at the same time, of course.
As you might expect, the thing isn’t FAA-approved yet and we wonder if it ever will be. The company plans remote control flights later this year and, even later, actual piloted flights. You can see more from Mayman Aerospace which is related to JetPack (which, of course, makes jet packs).
“Don’t worry, that’ll buff right out.” Alarming news this week as the James Webb Space Telescope team announced that a meteoroid had hit the space observatory’s massive primary mirror. While far from unexpected, the strike on mirror segment C3 (the sixth mirror from the top going clockwise, roughly in the “south southeast” position) that occurred back in late May was larger than any of the simulations or test strikes performed on Earth prior to launch. It was also not part of any known meteoroid storm in the telescope’s orbit; if it had been, controllers would have been able to maneuver the spacecraft to protect the gold-plated beryllium segments. The rogue space rock apparently did enough damage to be noticeable in the data coming back from the telescope and to require adjustment to the position of the mirror segment. While it certainly won’t be the last time this happens, it would have been nice to see one picture from Webb before it started accumulating hits.
[Sevan Janiyan] shares their research on putting an open FPGA toolchain together. Specifically, this is an open toolchain for the Sipeed Nano Tang FPGAs, which are relatively cheap offerings by Sipeed from China. The official toolchain is proprietary and requires you to apply for a license that’s to be renewed every year. There’s a limited educational version you can use more freely, but of course, that’s not necessarily sufficient for comfortable work.
This toolchain relies on the apicula project, an effort to reverse-engineer, reimplement and document the Gowin FPGA bitstream format, as well as the gowin integration for nextpnr (an open tool for FPGA place-and-route). With a combination of yosys, apicula, nextpnr and openFPGAloader, [Sevan] put together a set of commands you can use to build gateware for your Nano Tang FPGAs – without any proprietary limitations blocking your way. They show a basic blinkie demo, and also a demo that successfully operates a parallel LCD connected to the board.
The availability of open toolchains for FPGAs has always been somewhat of a sore point. Wondering about open FPGA toolchains? This Supercon 2019 talk by Tim [Mithro] Ansell will get you up to speed!
We thank [feinfinger (sneezing)] for sharing this with us!
[Konrad Dybcio] tells about his journey booting Linux on A7/8/8X processors, playing around with an old iPhone 5 he’s got in a drawer. It’s been a two-year “revisit every now and then” journey, motivationally fueled by the things like Linux on M1 Macs announcement. In the end, what we have here is a way to boot mainline Linux on a few less-than-modern but still very usable iPhones, and a fun story about getting there.
[Konrad]’s work is based on the Sandcastle project research, but he couldn’t quite figure out how to make their code work, and had to make sense of it as he went. At some point, he got stuck on enabling the MMU, which was the main roadblock for a while. Joined by another developer intrigued by Apple hardware, they were hacking away at it, developing tools and neat tricks on their way, but to no avail. With the framebuffer accessible and no other decent debugging methods in sight, he tells about a code snippet they wrote that printed register values as valid barcodes Continue reading “Boot Mainline Linux On Apple A7, A8 And A8X Devices”→
One of the drawbacks of being an early adopter is that you might end up investing in equipment that becomes obsolete rather quickly. Although it’s clear that electric vehicles are here to stay, those who bought a charging station for their EV a few years ago may find it slow and incompatible with modern cars or billing networks, necessitating an upgrade to one of the latest models.
If you don’t mind tinkering, these older chargers can provide an excellent base to construct your own state-of-the-art charging station, as [James] over at Diary-of-a-Geek did. He bought a Chargepoint CT2000 series charger and installed a brand-new charging unit inside based on OpenEVSE components. The CT2000 is an older model that’s no longer manufactured, and although it can still connect to Chargepoint’s network, a subscription renewal would cost several thousand dollars. [James] was not willing to make that investment for a unit that he was going to install at home anyway, so he decided to buy replacement parts from OpenEVSE, a supplier of open-source EV charging stations and components.
The OpenEVSE charging controller sitting on the ChargePoint bracket
The insides of a charging station are actually pretty simple, since the real battery charger is inside the car: the station just contains a beefy contactor to switch the AC current on or off, along with some circuitry to measure the current flowing and an interface to connect to a payment network of some sort. The first step therefore was to hook up the contactor and current transformer to the OpenEVSE controller. This was easy since the new part was way smaller than the original and could simply be mounted onto an existing bracket.
The second step was to provide the user interface and network connections. [James] removed the displays and wireless systems from the head unit and cut a large hole into the front to provide space for new LCD displays. A set of status LEDs plus WiFi connections completed the system, which now looks just as professional as the original. Tests showed that the LCDs were hard to read in bright sunlight, so [James] replaced them with OLED displays, but otherwise the renovated charging station worked perfectly.
Of course, working with high voltages and large currents requires the proper skills and tools, which [James] clearly has available; he also stresses the importance of including a ground-fault circuit interruptor in any equipment placed outdoors. He isn’t the only one to make his own charging station either. If you’re confused by the many types of EV charging connectors, have a look at our recent article describing all those different plugs and sockets. Thanks for the tip, [Kevin]!
We’ve seen hackers run DOOM on a variety of appliances, from desk phones to pregnancy tests. Now, the final frontier has been conquered – we got DOOM to run on an x86 machine. Of course, making sure we utilize your PC hardware to its fullest, we have to forego an OS. Here are two ways you can run the classic shooter without the burden of gigabytes of bloated code in the background.
[nic3-14159] implemented this first version as a payload for coreboot, which is an open-source BIOS/UEFI replacement for x86 machines. Some might say it’s imperfect — it has no sound support, only works with PS/2 keyboards, and exiting the game makes your computer freeze. However, it’s playable, and it fits into your BIOS flash chip.
But what if your computer hasn’t yet been blessed with a free BIOS replacement? You might like this UEFI moduleDOOM port instead, originally made by [Warfish] and then built upon by [Cacodemon345]. To play this, you only need to compile the binary and an UEFI shell, then use the “Load EFI Shell” option in your UEFI menu – something that’s widely encountered nowadays. This version also lacks sound, but is a bit more fully featured due to all the facilities that UEFI provides for its payloads.
Of course there’s far more efficient ways to slay demons on your computer, but even if they aren’t necessarily practical from a gaming standpoint, these two projects serve as decent examples of Coreboot and UEFI payloads. BIOS replacements like coreboot take up so little space, we’ve even seen Windows 3.1 fit alongside coreboot in the BIOS chip. Wondering what UEFI is, even? Here’s a primer for you. And, if you don’t mind the exceptional bloat of a stripped-down Linux install, here’s a Linux image built from the ground up to run DOOM specifically.
