Ben Eater Vs. Microsoft BASIC

[Ben Eater]’s breadboard 6502 computer is no stranger to these parts, so it was a bit of a surprise that when [Mark] wrote in asking us if we’d covered [Ben]’s getting MS BASIC running on the breadboard, that our answer was “no”. Well, that changes today!

This is a three-part video series, documenting how [Ben Eater] ports a 1977 version of MS BASIC to his 6502-based computer. The first video is all about just getting the BASIC up and working. It’s full of detail about how MS BASIC adapts to different architectures on the inside, and [Ben] essentially defines his own along the way.

Once he has BASIC working, the next two videos are about making it work not just with the serial terminal that he has attached, but also with the LCD display peripheral he has plugged into the breadboard. BASIC fans will not be surprised to see that it’s all about using POKE. But that ends up being to slow, so he extends it out with his own LCDPRINT command written in assembly.

Now that he can write a character to the LCD, he wants to be able to pass it a string: LCDPRINT “Hello world”. But that requires his command to be able to parse a string, and this has him diving down the rabbit hole into how MS BASIC parses strings, handles evals, and so on. If you want to know how MS BASIC works on the inside, this is the video for you. This video makes a lot of use of wozmon, which seems an almost ideal tool for this kind of low-level poking around.

All of this is done in [Ben]’s very well rehearsed, accessible, but pulling-no-punches style. Get ready to nerd out. All three of the videos are embedded just below the break.

While it’s not the Altair BASIC that Bill himself was writing about last week, it’s probably a direct descendent, and reading about the Altair version was what spurred [Mark Stevens] to send us the tip. Thanks!

Continue reading “Ben Eater Vs. Microsoft BASIC”

Inside An Edison Phonograph

If you think of records as platters, you are of a certain age. If you don’t remember records at all, you are even younger. But there was a time when audio records were not flat — they were drums, which was how the original Edison phonograph worked. [Our Own Devices] did a video earlier showing one of these devices, but since it was in a museum, he didn’t get to open it up. Lucky for us, he now has one of his own, and we get to see inside in the video below.

Ironically, Edison was deaf yet still invented the phonograph. While he did create the working phonograph — his self-identified most important invention — the original invention wasn’t commercially viable. You could record and playback audio on tin foil wrapped around a drum. But you couldn’t remove the foil without destroying it.

Continue reading “Inside An Edison Phonograph”

How Shrinking Feature Size Made Modern Wireless Work

If you’re living your life right, you probably know what as MOSFET is. But do you know the MESFET? They are like the faster, uninsulated, Schottky version of a MOSFET, and they used to rule the roost in radio-frequency (RF) silicon. But if you’re like us, and you have never heard of a MESFET, then give this phenomenal video by [Asianometry] a watch. In it, among other things, he explains how the shrinking feature size in CMOS made RF chips cheap, which brought you the modern cellphone as we know it.

The basic overview is that in the 1960s, most high-frequency stuff had to be done with discrete parts because the bipolar-junction semiconductors of the time were just too slow. At this time, MOSFETs were just becoming manufacturable, but were even slower still. The MESFET, without its insulating oxide layer between the metal and the silicon, had less capacitance, and switched faster. When silicon feature sizes got small enough that you could do gigahertz work with them, the MESFET was the tech of choice.

As late as the 1980s, you’d find MESFETs in radio devices. At this time, the feature size of the gates and the thickness of the oxide layer in MOSFETs kept them out of the game. But as CPU manufacturers pushed CMOS features smaller, not only did we get chips like the 8086 and 80386, two of Intel’s earliest CMOS designs, but the tech started getting fast enough for RF. And the world never looked back.

If you’re interested in the history of the modern monolithic RF ICs, definitely give the 18-minute video a watch. (You can skip the first three or so if you’re already a radio head.) If you just want to build some radio circuits, this fantastic talk from [Michael Ossmann] at the first-ever Supercon will make you an RF design hero. His secrets? Among them, making the most of exactly these modern everything-in-one-chip RF ICs so that you don’t have to think about that side of things too hard.

Thanks [Stephen] for the tip!

Continue reading “How Shrinking Feature Size Made Modern Wireless Work”

Multifunctional USB controlled PCB on blue background

How A Tiny Relay Became A USB Swiss Army Knife

Meet the little board that could: [alcor6502]’s tiny USB relay controller, now evolved into a multifunction marvel. Originally built as a simple USB relay to probe the boundaries of JLCPCB’s production chops, it has become a compact utility belt for any hacker’s desk drawer. Not only has [alcor6502] actually built the thing, he even provided instructions. If you happened to be at Hackaday in Berlin, you now might even own one, as he handed out twenty of them during his visit. If not, read on and build it yourself.

This thing is not just a relay, and that is what makes it special. Depending on a few solder bridges and minimal components, it shape-shifts into six different tools: a fan controller (both 3- and 4-pin!), servo driver, UART interface, and of course, the classic relay. It even swaps out a crystal oscillator for USB self-sync using STM32F042‘s internal RC – no quartz, less cost, same precision. A dual-purpose BOOT0 button lets you flash firmware and toggle outputs, depending on timing. Clever reuse, just like our mothers taught us.

It’s the kind of design that makes you want to tinker again. Fewer parts. More function. And that little smile when it just works. If this kind of clever compactness excites you too, read [alcor6502]’s build log and instructions here.

If You’re 3D Scanning, You’ll Want A Way To Work With Point Clouds

3D scanning is becoming much more accessible, which means it’s more likely that the average hacker will use it to solve problems — possibly odd ones. That being the case, a handy tool to have in one’s repertoire is a way to work with point clouds. We’ll explain why in a moment, but that’s where CloudCompare comes in (GitHub).

Not all point clouds are destined to be 3D models. A project may call for watching for changes in a surface, for example.

CloudCompare is an open source tool with which one can load up and do various operations on point clouds, including generating mesh models from them. Point clouds are what 3D scanners create when an object is scanned, and to become useful, those point clouds are usually post-processed into 3D models (specifically, meshes) like an .obj or .stl file.

We’ve gone into detail in the past about how 3D scanning works, what to expect from it, and taken a hands-on tour of what an all-in-one wireless scanner can do. But what do point clouds have to do with getting the most out of 3D scanning? Well, if one starts to push the boundaries of how and to what purposes 3D scanning can be applied, it sometimes makes more sense to work with point clouds directly instead of the generated meshes, and CloudCompare is an open-source tool for doing exactly that.

For example, one may wish to align and merge two or more different clouds, such as from two different (possibly incomplete) scans. Or, you might want to conduct a deviation analysis of how those different scans have changed. Alternately, if one is into designing wearable items, it can be invaluable to be able to align something to a 3D scan of a body part.

It’s a versatile tool with numerous tutorials, so if you find yourself into 3D scanning but yearning for more flexibility than you can get by working with the mesh models — or want an alternative to modeling-focused software like Blender — maybe it’s time to work with the point clouds directly.

A Look Inside MacPaint

Usually when we talk about retrocomputing, we want to look at — and in — some old hardware. But [Z→Z] has a different approach: dissecting MacPaint, the Apple drawing program from the 1980s.

While the program looks antiquated by today’s standards, it was pretty hot stuff back in the day. Things we take for granted today were big deals at the time. For example, being able to erase a part of something you drew prompted applause at an early public demo.

We enjoyed the way the program was tested, too. A software “monkey” was made to type keys, move things, and click menus randomly. The teardown continues with a look inside the Pascal and assembly code with interesting algorithms like how the code would fill an area with color.

The program has been called “beautifully organized,” and [Z→Z] examines that assertion. Maybe the brilliance of it has been overstated, but it did work and it did influence many computer graphics programs over the years.

We love digging through old source code. Even old games. If you do your own teardowns, be sure to send us a tip.

Disney’s Bipedal, BDX-Series Droid Gets The DIY Treatment

[Antoine Pirrone] and [Grégoire Passault] are making a DIY miniature re-imagining of Disney’s BDX droid design, and while it’s still early, there is definitely a lot of progress to see. Known as the Open Duck Mini v2 and coming in at a little over 40 cm tall, the project is expected to have a total cost of around 400 USD.

The inner workings of Open Duck Mini use a Raspberry Pi Zero 2W, hobby servos, and an absolute-orientation IMU.

Bipedal robots are uncommon, and back in the day they were downright rare. One reason is that the state of controlled falling that makes up a walking gait isn’t exactly a plug-and-play feature.

Walking robots are much more common now, but gait control for legged robots is still a big design hurdle. This goes double for bipeds. That brings us to one of the interesting things about the Open Duck Mini v2: computer simulation of the design is playing a big role in bringing the project into reality.

It’s a work in progress but the repository collects all the design details and resources you could want, including CAD files, code, current bill of materials, and links to a Discord community. Hardware-wise, the main work is being done with very accessible parts: Raspberry Pi Zero 2W, fairly ordinary hobby servos, and an BNO055-based absolute orientation IMU.

So, how far along is the project? Open Duck Mini v2 is already waddling nicely and can remain impressively stable when shoved! (A “testing purposes” shove, anyway. Not a “kid being kinda mean to your robot” shove.)

Check out the videos to see it in action, and if you end up making your own, we want to hear about it, so remember to send us a tip!