These days, if you want to code a game for the original Nintendo Entertainment System, it’s about as easy as downloading an assembler, firing up Notepad, and running the ROMs you cook up in any one of a variety of emulators. In the 1980s none of those things existed, and the process was a little more complicated – as demonstrated by [Tyler Barnes] in the video embedded below.
[Tyler] has put together a 40-minute guide on what it takes to get to “Hello World” – or more accurately, a simple pink screen – on the NES, using period-correct hardware. He starts the process by formatting some floppy disks and whipping up some basic assembly code on an Apple IIe, which gets run through the Merlin assembler for the 6502. It’s particularly convenient as the Apple II line and the NES both run the same CPU. From there it’s a case of using a standalone EPROM programmer to verify some appropriately-datecoded chips are empty, before programming them in a special add-on card for the Apple II. From there, the EPROMs are loaded into a cart custom modified with chip sockets, where it can be inserted into a NES for testing.
It’s a tedious process, with just the programming side of things taking on the order of ten to twenty minutes with a few fiddly steps along the way. While there are likely some efficiency gains to be had that were used by studios back in the day, it remains clear that development in this era was a much slower process.
Of course, if you prefer your Nintendo homebrew a couple generations hence, consider getting stuck in on the Nintendo 64. Video after the break.
Continue reading “What NES Development Looks Like On The Apple II”
In case you wanted to run WordStar on your Mac, [Tom Harte] offers CP/M for OS/X, and it looks like it would be a lot of fun. Of course you might be happier running Zork or Turbo Pascal, and you can do that, too.
There are plenty of Z80 emulators that can run CP/M, but what we found most interesting about this one is that it is written in Objective C, a language with a deep history in the Mac and NeXT worlds.
Continue reading “Apple Gets CP/M”
The Apple AirTag is a $29 Bluetooth beacon that sticks onto your stuff and helps you locate it when lost. It’s more than just a beeper though, the idea is that it can be silently spotted by any iDevice — almost like a crowd-sourced mesh network — and its owner alerted of its position wherever they are in the world.
There are so many questions about its privacy implications despite Apple’s reassurances, so naturally it has been of great interest to those who research such things. First among those working on it to gain control of its nRF52832 microcontroller is [Stacksmashing], who used a glitching technique whereby the chip’s internal power supply is interrupted with precise timing, to bypass the internally enabled protection of its debug port. The firmware has been dumped, and of course a tag has been repurposed for the far more worthwhile application of Rickrolling Bluetooth snoopers.
The idea of a global network of every iDevice helping reunite owners with their lost possessions is on the face of it a very interesting one, and Apple are at great pains on the AirTag product page to reassure customers about the system’s security. On one hand this work opens up the AirTag as a slightly expensive way to get an nRF microcontroller for other applications, but the real value will come as the firmware is analysed to see how at the tag itself works.
[Stacksmashing] has appeared on these pages many times before, often in the context of Nintendo hardware. Just one piece of work is the guide to opening up a Nintendo Game and Watch.
An old joke from the Linux community about its prevalence in computing quips that Linux will run on anything, including some animals. While the joke is a little dated, it is true that Linux can run on just about any computing platform with a certain amount of elbow grease. The current exception is the new Apple M1 silicon, although one group called Asahi Linux is currently working to get Linux running on this novel hardware as well.
While the Apple M1 is specifically built to run macOS, there’s no technical reason why Linux couldn’t run on it once all of the kinks are ironed out. This progress report from last month outlines some of the current areas of focus, especially around booting non-Mac kernels. The new Apple silicon runs on an ARM processor and because of this it functions more like an embedded device than a PC with standardized BIOS or UEFI. This means a lot of workarounds to the proprietary boot process have to be created to get a Linux kernel to boot. Luckily there are already versions of Linux that run on ARM so a lot of work has already been done, but there’s still much ahead.
While it’s probably best to buy an x86 machine for the time being if you need a Linux on your own personal machine, it seems like only a matter of time until all of the barriers to Linux are overcome on the M1 silicon. If Linux is able to take advantage of some of the efficiency and performance benefits of these chips, it could be a game-changer in the Linux world and at least give us all another option for hardware. Of course, we will still be needing software that can run on ARM, too.
Thanks to [Mark] for the tip!
Apple’s “Find My” service allows users to track their missing devices by leveraging a worldwide network of location-aware iGadgets. With millions of iPhones and Macs out in the wild listening for the missing device’s Bluetooth advertisements and relaying their findings to the Cupertino Mothership, it’s a highly effective way of tracking hardware so long as it stays in relatively urban areas. Unfortunately, the system is completely proprietary and non-Apple devices aren’t invited to play.
Or at least, that used to be the case. A project recently released by the [Secure Mobile Networking Lab] called OpenHaystack demonstrates how generic devices can utilize Apple’s Find My network by mimicking the appropriate Bluetooth Low Energy (BLE) broadcasts. Currently they have a firmware image for the BBC micro:bit, as well as a Python script for Linux, that will allow you to spin up an impromptu Find My target. But the team has also published all the information required to implement similar functionality on other BLE-capable devices and microcontrollers, so expect the list of supported hardware to grow shortly.
Somewhat ironically, while OpenHaystack allows you to track non-Apple devices on the Find Me tracking network, you will need a Mac computer to actually see where your device is. The team’s software requires a computer running macOS 11 (Big Sur) to run, and judging by the fact it integrates with Apple Mail to pull the tracking data through a private API, we’re going to assume this isn’t something that can easily be recreated in a platform-agnostic way. Beyond the occasional Hackintosh that might sneak in there, it looks like Tim Cook might have the last laugh after all.
It’s not immediately clear how difficult it will be for Apple to close this loophole, but the talk of utilizing a private API makes us think there might be a built-in time limit on how long this project will be viable. After all, Big Tech doesn’t generally approve of us peons poking around inside their machinations for long. Though even if Apple finds a way to block OpenHaystack, it’s expected the company will be releasing “AirTags” sometime this year which will allow users to track whatever objects they like through the system.
If we cast our minds back a few decades, almost all computers were a beige colour. “Beige box” even became a phrase for a generic PC, such was their ubiquity. Long before PCs though there were other beige computers, and probably one of the first to land on the desks of enthusiasts rather than professionals was the Apple ][. But exactly what beige colour was it? It’s a question that interested [Ben Zotto], and his quest led him through a fascinating exploration of a colour most of us consider to be boring.
We’re used to older beige computers becoming yellow with time, as the effect of light and age causes the fire retardants in their plastic to release bromine. But the earlier Apple products haven’t done this, because their beige came not from the plastic but from a paint. [Ben] was lucky enough to find a small pot of touch-up paint from Apple that was made available to dealers, so notwithstanding any slight pigment changes from its age, he set off in pursuit of its origin.
Along the way to identifying a modern Pantone shade (Pantone 14–0105 TPG, for the curious) he treats us to a cross-section of Apple’s early colour history with reference to the memories of early Apple luminaries. He even suggests readily available shades that could suffice, pointing to Gloss Almond Rust-Oleum spray paint.
So should you wish to colour-match to an early Apple, now you can. If you have a Commodore or an Atari though, maybe your task is a little easier.
Even those critical of Apple as a company have to admit that they were really onto something with the iPod. The click wheel was a brilliant input device, and the simplicity of the gadget’s user interface made it easy to get to the music you wanted with a minimum of hoop jumping. Unfortunately it was a harbinger of proprietary software and DRM, but eventually there were a few open source libraries that let you put songs on the thing without selling your soul to Cupertino.
Of course, modern users expect a bit more than what the old hardware can deliver. Which is why [Guy Dupont] swapped the internals of his iPod Classic with a Raspberry Pi Zero W. This new Linux-powered digital audio player is not only capable of playing essentially any audio format you throw at it, but can also tap into streaming services such as Spotify. But such greatness doesn’t come easy; to pull this off, he had to replace nearly every component inside the player with the notable exception of the click wheel itself. Good thing the Classics were pretty chunky to begin with.
In addition to the Pi Zero running the show, he also had to fit a 1000 mAh battery, its associated charging and boost modules, a vibration motor for force feedback, and a 2″ LCD from Adafruit. The display ended up being almost the perfect size to replace the iPod’s original screen, and since it uses composite video, only took two wires to drive from the Pi. To interface with the original click wheel, [Guy] credits the information he pulled from a decade-old Hackaday post.
Of course with a project like this, the hardware is only half the story. It’s one thing to cram all the necessary components inside the original iPod enclosure, but by creating such an accurate clone of its iconic UI in Python, [Guy] really took things to the next level. Especially since he was able to so seamlessly integrate support for Spotify, a feature the Apple devs could scarcely have imagined back at the turn of the millennium. We’re very interested in seeing the source code when he pushes it to the currently empty GitHub repository, and wouldn’t be surprised if it set off a resurgence of DIY iPod clones.
We’ve seen modern hardware grafted onto the original iPod mainboard, and over the years a few hackers have tried to spin up their own Pi-based portable music players. But this project that so skillfully combines both concepts really raises the bar.
Continue reading “Raspberry Pi Zero Powers Spotify Streaming IPod”