A BASIC Interpreter For The Raspberry Pi Pico

It’s pretty easy to program the Raspberry Pi Pico in Python, or you can use C or C++ if you so desire. However, if you fancy the easy language of yesteryear, you might like PiccoloBASIC from [Gary Sims].

Putting it simply, piccoloBASIC is a BASIC interpreter that runs on the Raspberry Pi Pico. It features all the good bits of BASIC such as GOTO and GOSUB commands, that fancier languages kind of look down upon. It’s also got enough built-in routines to handle regular programming life, like sleeps, delays, a basic pseudorandom number source, trigonometric functions, and the ability to deal with floating point numbers. As far as microcontroller tasks go, it’s got rudimentary support for talking to GPIOs right now via the pinon and pinoff commands. However, it’s probably not the way to go if you want to bit-bang an SD card to within an inch of its speed rating.

Down the road, [Gary] hopes to add support for features like the Pico’s I2C, SPI, and PIO hardware, along with networking protocols and Bluetooth. PEEK and POKE are also hopefully on the way for those that like to fiddle with memory directly.

Meanwhile, if you’re looking for a different yet similar take, explore the port of MMBasic to the Pico platform. Video after the break.

Continue reading “A BASIC Interpreter For The Raspberry Pi Pico”

Get Your Leafy Meats

Some of us jokingly refer to our hobbies as “mad science,” but [Justin] from The Thought Emporium could be one Igor away from living up to the jibe. The latest project to come out of the YouTube channel, video also after the break, outlines a map for creating an artificial organism in their new lab. The purpose is to test how far a citizen scientist can push the boundary of bioengineering. The stated goal is to create a swimming entity with a skeleton. The Thought Emporium also has a neuron project in the works, hinting at a potential crossover.

The artifishal [sic] organism has themes at the micro and macro scale. [Justin] says, “Cells are like little nano-robots. Mainly in the sense that they just follow their built-in instructions to the best of their ability.” At the multi-cellular level, the goal is to program something to actuate muscle tissue rhythmically to sustain locomotion. The method for creating living parts is decellularization and recellularization, a technique we heard about at Hackaday Belgrade.

The Thought Emporium is improving upon its protocol which removes cells from their “scaffolding” to repopulate it with the desired type, muscle in this case. Cellular scaffolds retain the shape of whatever they were, so whatever grows on them determines what they become. Once the technique of turning a leaf into muscle fibers is mastered, the next step will be creating bones with a different cell line that will mineralize the scaffold. Optimizing the processes and combining the results may show the world what is possible with the dedication of citizen bioengineers.

Regenerative medicine is looking at replacement human-parts with similar techniques. We are eager to see fish that digest plastic.

Continue reading “Get Your Leafy Meats”

Meshtastic For The Greater Good

Last week, my city was hit by a tornado. That’s not surprising here in Oklahoma, and thankfully this event was an F0 or possibly even an EF0 — a really weak tornado. Only a couple roofs collapsed, though probably half the houses in town are going to need roof repairs, thanks to the combination of huge hail and high winds. While it wasn’t too bad, power did go down in a few places around town, and this led to an interesting series of events.

Chat messages were coming in like this: “That was a [power] flicker, yeah. Even took down my Internet.” Followed by “Whee, [fiber Internet] got knocked out and now Starlink has too many clouds in the way.” And after ten minutes of silence, we got a bit worried to see “Time to hide under a bed. … Is cell service back?” It is a bit spooky to think about trying to help neighbors and friends after a disaster, in the midst of the communication breakdown that often follows. If he had needed help, and had no working communications, how long would it have taken for us to go check on him?
Continue reading “Meshtastic For The Greater Good”

A Simple Guide To Bit Banged I2C On The 6502

We covered [Anders Nielsen]’s 65duino project a short while ago, and now he’s back with an update video showing some more details of bit-banging I2C using plain old 6502 assembly language.

Obviously, with such a simple system, there is no dedicated I2C interface hardware, so the programmer must take care of all the details of the I2C protocol in software, bit-banging it out to the peripheral and reading back the response one bit at a time.

The first detail to concern us will be the I2C addresses of the devices being connected to the bus and how low-level bit manipulation is used to turn the 7-bit I2C address into the byte being bit-banged. As [Anders] shows, setting a bit is simply a logical-OR operation, and resetting a bit is a simple logical-AND operation using the inversion (or one’s complement) bit to reset to form a bitmask. As many will already know, this process is necessary to code for a read or a write I2C operation. A further detail is that I2C uses an open-collector connection scheme, which means that no device on the bus may drive the bus to logical high; instead, they must release the drive by going to the high impedance state, and an external pull-up resistor will pull the bus high. The 6532 RIOT chip (used for I/O on the 65unio) does not have tristate control but instead uses a data direction register (DDR) to allow a pin to be an input. This will do the job just fine, albeit with slightly odd-looking code, until you know what’s going on.

From there, it’s a straightforward matter to write subroutines that generate the I2C start, stop, and NACK conditions that are required to write to the SSD1306-based OLED to get it to do something we can observe. From these basic roots, through higher-level subroutines, a complete OLED library in assembly can be constructed. We shall sit tight and await where [Anders] goes next with this!

We see I2C-connected things all the time, like this neat ATtiny85-based I2C peripheral, and whilst we’re talking about the SSD1306 OLED display controller, here’s a hack that shows just how much you can push your luck with the I2C spec and get some crazy frame rates.

Continue reading “A Simple Guide To Bit Banged I2C On The 6502”

This Week In Security: ACME.sh, Leaking LEDs, And Android Apps

Let’s Encrypt has made an enormous difference to the landscape of the web. The protocol used for authenticating and receiving certificates, ACME, has spawned quite a few clients of various flavors. Some are written in Rust, some in Python or Go, and a few in straight Bash shell script. One of those last ones, acme.sh, was doing something odd when talking to a particular “Certificate Authority”, HiCA. This pseudo-CA only supports acme.sh, and now we know why. The folks behind HiCA found an RCE exploit in acme.sh, and decided to use that exploit to do certificate issuance with more “flexability”. Oof.

The nuts and bolts here is that HiCA was working as a CA-in-the-Middle, wrapping other CA’s authentication services. Those services don’t support ACME authentication at all, and HiCA used the acme.sh vulnerability to put the authentication token in the place SSL.com expected to find it. So, just a good community member offering a service that ACME doesn’t quite support, right?

Well, maybe not so innocent. The way it appears this works, is that the end user sends a certificate request to HiCA. HiCA takes that information, and initiates a certificate request off to SSL.com. SSL.com sends back a challenge, and HiCA embeds that challenge in the RCE and sends it to the end user. The end user’s machine triggers the RCE, which pushes the challenge token to the well-known location, and bypasses the ACME protection against exactly this sort of CA-in-the-middle situation.

The last piece of the authentication process is that the signing server reaches out over HTTP to the domain being signed, and looks for the token to be there. Once found, it sends the signed certificates to HiCA, who then forward them on to the end user. And that’s the problem. HiCA has access to the key of every SSL cert they handled. This doesn’t allow encryption, but these keys could be used to impersonate or even launch MitM attacks against those domains. There’s no evidence that HiCA was actually capturing or using those keys, but this company was abusing an RCE to put itself in the position to have that ability.

The takeaway is twofold. First, as an end user, only use reputable CAs. And second, ACME clients need to be hardened against potentially malicious CAs. The fact that HiCA only supported the one ACME client was what led to this discovery, and should have been a warning flag to anyone using the service. Continue reading “This Week In Security: ACME.sh, Leaking LEDs, And Android Apps”

The Fake Moon Landing Quarantine

We aren’t much into theories denying the moon landing around here, but [Dagomar Degroot], an associate professor at Georgetown University, asserts that the Apollo 11 quarantine efforts were bogus. Realistically, we think today that the chance of infection from the moon, of all places, is low. So claiming it was successful is like paying for a service that prevents elephants from falling through your chimney. Sure, it worked — there hasn’t been a single elephant!

According to [Degroot], the priority was to protect the astronauts and the mission, and most of the engineering money and effort went towards that risk reduction. The — admittedly low — danger of some alien plague wiping out life on Earth wasn’t given the same priority.

Continue reading “The Fake Moon Landing Quarantine”

A Nintendo 64 controller with a USB adapter

Play N64 Games The Right Way With This Classic Controller Adapter

Game consoles typically support a limited number of input devices, meaning that console games are often completely optimized for the default controller supplied with that platform. Nintendo’s tendency to completely reinvent their controllers pretty much every generation can therefore become a little irritating, especially when they also enable their newer consoles to play games from their back catalog. So when [Robson Couto] found that using the Switch’s Joy-Cons was a bit awkward for playing emulated Nintendo 64 games, he decided to figure out how to connect real N64 controllers to a Nintendo Switch.

While you can buy modern N64-style controllers for the Switch, even straight from Nintendo themselves, [Robson] thought it would be way more interesting to reuse an old controller and implement the translation step from scratch. In the video (embedded below) he takes a deep dive into all the timing details of the N64 controller protocol, which is basically a 1-wire setup, and explains how to use an STM32F411 BlackPill board to read out the controller’s buttons and joystick.

Next, he explores how to map the resulting data to the USB HID protocol used by the Switch. Most of the buttons have a clear one-on-one mapping, but since the “minus”, “capture” and “home” buttons are missing on the N64 controller, he chose to map these to button combinations unlikely to be used during regular gameplay. [Robson] also ran into the common issue of the analog joystick having a poorly-defined maximum range, for which he added a rudimentary auto-calibration feature.

Finally, he designed and 3D-printed a neat enclosure for his system with an N64 controller port on one side and a USB port on the other. By 3D-printing the whole thing he also avoided having to either source the non-standard connector or permanently modify his hardware. The end result of [Robson]’s project is an unobtrusive gadget that connects classic controllers to modern hardware – but of course, the reverse process is very much possible, too. If you want, you can even play N64 games with a mouse and keyboard.

Continue reading “Play N64 Games The Right Way With This Classic Controller Adapter”