The BBC Micro, Lovingly Simulated In VR

The BBC Micro was many peoples’ first exposure to home computing, and thanks to [Dominic Pajak], you can fire up this beloved hardware in WebXR. Is it an emulator? Yes, but it’s also much more than that.

The machine, the CRT, the keycaps, and even the sounds of the original keypresses are all brought to life as accurately as possible. The result is not just an emulator. It’s a lovingly-made BBC Micro simulator you can use with a VR headset. Or just use your browser and type on your real keyboard if you like.

Continue reading “The BBC Micro, Lovingly Simulated In VR”

Retro Hackintosh Made From Retro Parts

Apple as a company, has staked most of its future around being a “walled garden” where it controls everything from the hardware up through the user experience. In some ways this is good for users; the hardware is generally high quality and vetted by the company creating the software, making for a very uniform experience. This won’t stop some people from trying to get Apple’s operating systems and other software running on unapproved hardware though. These “Hackintosh” computers were much more common in the Intel era but this replica goes even further back to the Macintosh era.

Originally [Kevin] had ordered an authentic Macintosh with the intent of getting it working again, but a broken floppy disk drive and lack of replacement parts turned this project into a different beast. He used the Mac instead as a model for a new 3D-printed case, spending a ton of time sanding, filling, and finishing it to get it to look nearly indistinguishable from the original. The hardware going in this replica is an old Linux-based thin client machine running the Mini vMac operating system, with a modified floppy drive the computer uses to boot. A hidden SD card slot helps interface with modern computers. The display is a modern LCD, though a sheet of acrylic glued to the front panel replicates a bit of the CRT curve.

Click through to read on!

Continue reading “Retro Hackintosh Made From Retro Parts”

Yuzu And Citra Emulators Shut Down After Legal Pressure From Nintendo

In a move that came rather like a surprise to many, the company behind the well-known Switch and 3DS emulators Yuzu and Citra – Tropic Haze LLC – as reported by PC Gamer has shutdown both projects and associated websites as part of a US$2.4M settlement with Nintendo with a last message left on the Yuzu website. This comes in the wake of Nintendo suing Tropic Haze LLC over the Yuzu emulator, claiming that there’s ‘no lawful way to use Yuzu’, as it requires files extracted from a real Switch device to decrypt game files. Although Citra is not part of the lawsuit, it being made by the same developers seems to have resulted in it getting axed along with Yuzu as collateral damage.

What makes this issue so legally hairy is that even though an emulator by itself isn’t illegal, requiring proprietary firmware and keys already gets one into contested territory about the legality of dumping said files from a console, even if you own it. This was already an issue with the first Playstation emulators, which require the Playstation BIOS image to even boot, but left the emulator developers mostly untouchable. What seems to have set off Nintendo’s lawyers here would seem to be the way that the Yuzu developers leaned into the copyright infringement (often incorrectly called ‘piracy’) angle, giving Nintendo’s legal team enough exposed flesh to launch a ballistic legal strike.

Continue reading “Yuzu And Citra Emulators Shut Down After Legal Pressure From Nintendo”

Apple System 7… On Solaris?

While the Unix operating systems Solaris and HP-UX are still in active development, they’re not particularly popular anymore and are mostly relegated to some enterprise and data center environments They did enjoy a peak of popularity in the 90s during the “wild west” era of windowed operating systems, though. This was a time when there were more than two mass-market operating systems commercially available, with many companies fighting for market share. This led to a number of efforts to get software written for one operating system to run on others, whether that was simply porting software directly or using some compatibility layer. Surprisingly enough it was possible in this era to run an entire instance of Mac System 7 within either of these two Unix operating systems, and this was an officially supported piece of Apple software.

The software was called the Macintosh Application Environment (MAE), and was an effort by Apple to bring Macintosh System 7 applications to various Unix-based operating systems, including Solaris and HP-UX. This was a time before Apple’s OS was Unix-compliant, and MAE provided a compatibility layer that translated Macintosh system calls and application programming interfaces (APIs) into the equivalent Unix calls, allowing Mac software to function within the Unix environments. [Lunduke] outlines a lot of the features of this in his post, including some of the details the “scaffolding” allowing the 68k processor to be emulated efficiently on the hardware of the time, the contents of the user manual, and even the memory management and layout.

What’s really jarring to anyone only familiar with Apple’s modern “walled garden” approach is that this is an Apple-supported compatibility layer for another system. At the time, though, they weren’t the technology giant they are today and had to play by a different set of rules to stay viable. Quite the opposite, in fact: they almost went out of business in the mid-90s, so having their software run on as many machines as possible would have been a perk at the time. While this era did have major issues with cross-platform compatibility, there was some software that attempted to solve these problems that are still in active development today.

Thanks to [Stephen] for the tip!

Teensy Stands In For The Motorola 68k

While it might not seem like it today, there was a time in the not-too-distant past where Motorola was the processor manufacturer. They made chips for everything, but the most popular was arguably the 68000 or 68k. It’s still has a considerable following today, largely among retrocomputing enthusiasts or those maintaining legacy hardware. For those wanting to dip their toes into this world, this Motorola 68000 emulator created by [Ted Fried] may be the thing needed to discover the magic of these once-ubiquitous chips.

The emulator itself runs on a Teensy 4.1, a 32-bit ARM microcontroller running at 600 MHz — giving it enough computing power to act as a cycle-accurate emulator not only for the 68000 CPU but also the local bus interface, in this case for a Mac 512K. This capability also makes it a drop-in replacement for the 68000 in these older Macs and the original hardware in these computers won’t notice much of a difference. A few tricks are needed to get it fully operational though, notably using a set of latches to make up for the fact that the Teensy doesn’t have the required number of output pins to interface one-to-one with the original hardware.

While the emulator may currently be able to replace the hardware and boot the computer, there is still ongoing development to get every part of the operating system up and working. The source code is available on the project’s GitHub page though so any updates made in the future can be found there. And if you have a Mac 128k and still haven’t upgraded to the 512k yet, grab one of these memory switching modules for the upgrade too.

Continue reading “Teensy Stands In For The Motorola 68k”

Bus Sniffing The Model 5150 For Better Emulation

At the risk of stating the obvious, a PC is more than just its processor. And if you want to accurately emulate what’s going on inside the CPU, you’d do well to pay attention to the rest of the machine, as [GloriousCow] shows us by bus-sniffing the original IBM Model 5150.

A little background is perhaps in order. Earlier this year, [GloriousCow] revealed MartyPC, the cycle-accurate 8088 emulator written entirely in Rust. A cycle-accurate emulation of the original IBM PC is perhaps a bit overkill, unless of course you need to run something like Area 5150, a demo that stretches what’s possible with the original PC architecture but is notoriously finicky about what hardware it runs on.

Getting Area 5150 running on an emulator wasn’t enough for [GloriousCow], though, so a deep dive into exactly what’s happening on the bus of an original IBM Model 5150 was in order. After toying with and wisely dismissing several homebrew logic analyzer solutions, a DSLogic U3Pro32 logic analyzer was drafted into the project.

Fitting the probes for the 32-channel instrument could have been a problem except for the rarely populated socket for the 8087 floating-point coprocessor on the motherboard. A custom adapter gave access to most of the interesting lines, including address and data buses, while a few more signals, like the CGA sync lines, were tapped directly off the video card.

Capturing one second of operation yielded a whopping 1.48 GB CSV file, but a little massaging with Python trimmed the file considerably. That’s when the real fun began, strangely enough in Excel, which [GloriousCow] used as an ad hoc but quite effective visualization tool, thanks to the clever use of custom formatting. We especially like the column that shows low-to-high transitions as a square wave — going down the column, sure, but still really useful.

The whole thing is a powerful toolkit for exploring the action on the bus during the execution of Area 5150, only part of which [GloriousCow] has undertaken as yet. We’ll be eagerly awaiting the next steps on this one — maybe it’ll even help get the demo running as well as 8088MPH on a modded Book8088.

Automation For The NES

Old hardware might not be anywhere close to as powerful as modern technology, but it does have a few perks. Aesthetics can of course drive the popularity of things like retro gaming systems, but the ease of understanding the underpinnings of their inner workings is also critical. The Nintendo Entertainment System, now nearly four decades old, is a relatively simple machine by modern standards and this lends the system to plenty of modifications, like this controller that allows the system to be somewhat automated.

The original NES controller used a fairly simple shift register to send button presses to the system. The system outputted a latch signal to the controller, the shift register would take as input the current state of the buttons, and then would send them one-by-one to the system at a rate of around 1000 times per second. These signals can be sent without a controller easily enough, too. This build uses a CD4021 shift register, which is the same as the original controller, but instead of reading button states it accepts its inputs from a separate computer via a latching circuit. In this case, the separate computer is a custom design that came about through adapting cassette storage for a 6502-based computer, but it could come from anything else just as easily.

With this system in place, it’s possible to automate gameplay to some extent. Since the system can’t get feedback about the game in its current state, it requires some precise timing to get it to play the game well, and a lot of tuning needs to go into it. This isn’t just a one-off, either. Similar methods are how we get tool-assisted speedruns of games and although these are often done in emulators instead of on real hardware, they can result in some interesting exploits.

Continue reading “Automation For The NES”