Supercon 2023: Building The Ultimate Apple IIe, Decades Later

The Apple II was launched in 1977, a full 47 years ago. The Apple IIe came out six years later, with a higher level of integration and a raft of new useful features. Apple eventually ended production of the whole Apple II line in 1993, but that wasn’t the end. People like [James Lewis] are still riffing on the platform to this day. Even better, he came to Supercon 2023 to tell us all about his efforts!

[James]’s talk covers the construction of the Mega IIe, a portable machine of his own design. As the name suggests, the project was based on the Mega II chip, an ASIC for which he had little documentation. He wasn’t about to let a little detail like that stop him, though.

The journey of building the Mega IIe wasn’t supposed to be long or arduous; the initial plan was to “just wire this chip up” as [James] puts it. Things are rarely so simple, but he persevered nonetheless—and learned all about the Apple II architecture along the way.

Continue reading “Supercon 2023: Building The Ultimate Apple IIe, Decades Later”

The Art Of Hackaday Hack Chat

Join us on Wednesday, May 15 at noon Pacific for the The Art of Hackaday Hack Chat with Joe Kim!

Here at Hackaday, we writers strive to bring you the freshest hacks and the best news from the world of engineering and science. When we miss the mark and make technical errors or stake out a controversial position on something, our readers will certainly let us know in the comments section. It’s a love-hate thing.

While we don’t always see eye to eye, there’s one thing that everyone seems to agree on: Hackaday’s art is amazing! Our unique look comes down to one man: art director Joe Kim. Joe’s creations have graced Hackaday’s pages for years, and his ability to come up with just the right art to illustrate subject matter that’s often complicated and abstract never ceases to amaze.

join-hack-chatA lot of you have asked about Hackaday’s art over the years, so we asked Joe to come on the Hack Chat to talk about the process of creating these mini masterpieces. If you’ve ever wondered about the art of Hackaday, or just wanted to say thanks for the visual feast, here’s your chance.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, May 15 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

Hackaday Links Column Banner

Hackaday Links: May 12, 2024

Don’t pack your bags for the trip to exoplanet K2-18b quite yet — it turns out that the James Webb Space Telescope may not have detected signs of life there after all. Last year, astronomers reported the possible presence of dimethyl sulfide there, a gas that (at least on Earth) is generally associated with phytoplankton in the ocean. Webb used its infrared spectrometer instruments to look at the light from the planet’s star, a red dwarf about 111 light-years away, as it passed through the hydrogen-rich atmosphere. The finding was sort of incidental to the discovery of much stronger signals for methane and carbon dioxide, but it turns out that the DMS signal might have just been overlap from the methane signal. It’s too bad, because K2-18b seems to be somewhat Earth-like, if you can get over the lack of oxygen and the average temperature just below freezing. So, maybe not a great place to visit, but it would be nice to see if life, uh, found a way anywhere else in the universe.

Attention Fortran fans: your favorite language isn’t quite dead yet. In fact, it cracked the top ten on one recent survey, perhaps on the strength of its numerical and scientific applications. The “Programming Community Index” is perhaps a bit subjective, since it’s based on things like Google searches for references to particular languages. It’s no surprise then that Python tops such a list, but it’s still interesting that there’s enough interest in a 67-year-old programming language to make it onto the list. We’d probably not advise building a career around Fortran, but you never know.

Continue reading “Hackaday Links: May 12, 2024”

Institutional Memory, On Paper

Our own Dan Maloney has been on a Voyager kick for the past couple of years. Voyager, the space probe. As a long-term project, he has been trying to figure out the computer systems on board. He got far enough to write up a great overview piece, and it’s a pretty good summary of what we know these days. But along the way, he stumbled on a couple old documents that would answer a lot of questions.

Dan asked JPL if they had them, and the answer was “no”. Oddly enough, the very people who are involved in the epic save a couple weeks ago would also like a copy. So when Dan tracked the document down to a paper-only collection at Wichita State University, he thought he had won, but the whole box is stashed away as the library undergoes construction.

That box, and a couple of its neighbors, appear to have a treasure trove of documentation about the Voyagers, and it may even be one-of-a-kind. So in the comments, a number of people have volunteered to help the effort, but I think we’re all just going to have to wait until the library is open for business again. In this age of everything-online, everything-scanned-in, it’s amazing to believe that documents about the world’s furthest-flown space probe wouldn’t be available, but so it is!

It makes you wonder how many other similar documents – products of serious work by the people responsible for designing the systems and machines that shaped our world – are out there in the dark somewhere. History can’t capture everything, and it’s down to our collective good judgement in the end. So if you find yourself in a position to shed light on, or scan, such old papers, please do! And then contact some nerd institution like the Internet Archive or the Computer History Museum.

Hackaday Podcast Episode 270: A Cluster Of Microcontrollers, A Rocket Engine From Scratch, And A Look Inside Voyager

Join Hackaday Editors Elliot Williams and Tom Nardi as they get excited over the pocket-sized possibilities of the recently announced 2024 Business Card Challenge, and once again discuss their picks for the most interesting stories and hacks from the last week. There’s cheap microcontrollers in highly parallel applications, a library that can easily unlock the world of Bluetooth input devices in your next project, some gorgeous custom flight simulator buttons that would class up any front panel, and an incredible behind the scenes look at how a New Space company designs a rocket engine from the ground up.

Stick around to hear about the latest 3D printed gadget that all the cool kids are fidgeting around with, a brain-computer interface development board for the Arduino, and a WWII-era lesson on how NOT to use hand tools. Finally, learn how veteran Hackaday writer Dan Maloney might have inadvertently kicked off a community effort to digitize rare documentation for NASA’s Voyager spacecraft.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download your very own copy of the podcast right about here.

Continue reading “Hackaday Podcast Episode 270: A Cluster Of Microcontrollers, A Rocket Engine From Scratch, And A Look Inside Voyager”

This Week In Security: TunnelVision, Scarecrows, And Poutine

There’s a clever “new” attack against VPNs, called TunnelVision, done by researchers at Leviathan Security. To explain why we put “new” in quotation marks, I’ll just share my note-to-self on this one written before reading the write-up: “Doesn’t using a more specific DHCP route do this already?” And indeed, that’s the secret here: in routing, the more specific route wins. I could not have told you that DHCP option 121 is used to set extra static routes, so that part was new to me. So let’s break this down a bit, for those that haven’t spent the last 20 years thinking about DHCP, networking, and VPNs.

So up first, a route is a collection of values that instruct your computer how to reach a given IP address, and the set of routes on a computer is the routing table. On one of my machines, the (slightly simplified) routing table looks like:

# ip route
default via 10.0.1.1 dev eth0
10.0.1.0/24 dev eth0

The first line there is the default route, where “default” is a short-hand for 0.0.0.0/0. That indicate a network using the Classless Inter-Domain Routing (CIDR) notation. When the Internet was first developed, it was segmented into networks using network classes A, B, and C. The problem there was that the world was limited to just over 2.1 million networks on the Internet, which has since proven to be not nearly enough. CIDR came along, eliminated the classes, and gave us subnets instead.

In CIDR notation, the value after the slash is commonly called the netmask, and indicates the number of bits that are dedicated to the network identifier, and how many bits are dedicated to the address on the network. Put more simply, the bigger the number after the slash, the fewer usable IP addresses on the network. In the context of a route, the IP address here is going to refer to a network identifier, and the whole CIDR string identifies that network and its size.

Back to my routing table, the two routes are a bit different. The first one uses the “via” term to indicate we use a gateway to reach the indicated network. That doesn’t make any sense on its own, as the 10.0.1.1 address is on the 0.0.0.0/0 network. The second route saves the day, indicating that the 10.0.1.0/24 network is directly reachable out the eth0 device. This works because the more specific route — the one with the bigger netmask value, takes precedence.

The next piece to understand is DHCP, the Dynamic Host Configuration Protocol. That’s the way most machines get an IP address from the local network. DHCP not only assigns IP addresses, but it also sets additional information via numeric options. Option 1 is the subnet mask, option 6 advertises DNS servers, and option 3 sets the local router IP. That router is then generally used to construct the default route on the connecting machine — 0.0.0.0/0 via router_IP.

Remember the problem with the gateway IP address belonging to the default network? There’s a similar issue with VPNs. If you want all traffic to flow over the VPN device, tun0, how does the VPN traffic get routed across the Internet to the VPN server? And how does the VPN deal with the existence of the default route set by DHCP? By leaving those routes in place, and adding more specific routes. That’s usually 0.0.0.0/1 and 128.0.0.0/1, neatly slicing the entire Internet into two networks, and routing both through the VPN. These routes are more specific than the default route, but leave the router-provided routes in place to keep the VPN itself online.

And now enter TunnelVision. The key here is DHCP option 121, which sets additional CIDR notation routes. The very same trick a VPN uses to override the network’s default route can be used against it. Yep, DHCP can simply inform a client that networks 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 are routed through malicious_IP. You’d see it if you actually checked your routing table, but how often does anybody do that, when not working a problem?

There is a CVE assigned, CVE-2024-3661, but there’s an interesting question raised: Is this a vulnerability, and in which component? And what’s the right solution? To the first question, everything is basically working the way it is supposed to. The flaw is that some VPNs make the assumption that a /1 route is a bulletproof way to override the default route. The solution is a bit trickier. Continue reading “This Week In Security: TunnelVision, Scarecrows, And Poutine”

Ask Hackaday: Do You Calibrate Your Instruments?

Like many of you, I have a bench full of electronic instruments. The newest is my Rigol oscilloscope, only a few years old, while the oldest is probably my RF signal generator that dates from some time in the early 1950s. Some of those instruments have been with me for decades, and have been crucial in the gestation of countless projects.

If I follow the manufacturer’s recommendations then just like that PAT tester I should have them calibrated frequently. This process involves sending them off to a specialised lab where their readings are compared to a standard and they are adjusted accordingly, and when they return I know I can trust their readings. It’s important if you work in an industry where everything must be verified, for example I’m certain the folks down the road at Airbus use meticulously calibrated instruments when making assemblies for their aircraft, because there is no room for error in a safety critical application at 20000 feet.

But on my bench? Not so much, nobody is likely to face danger if my frequency counter has drifted by a few Hz. Continue reading “Ask Hackaday: Do You Calibrate Your Instruments?”