If you keep up with the field of web development, you may have heard of WebAssembly. A relatively new kid on the block, it was announced in 2015, and managed to garner standardised support from all major browsers by 2017 – an impressive feat. However, it’s only more recently that the developer community has started to catch up with adoption and support.
So, what is it? What use case is so compelling that causes such quick browser adoption? This post aims to explain the need for WebAssembly, a conceptual overview of the technical side, as well as a small hands-on example for context.
The 1980s were the heyday of the venerable Z80, a processor that found its way into innumerable home computers, industrial systems, and yes — arcade machines. However, not everyone had a Z80 based machine at home, and so sometimes porting is required. [Glen] is tackling this with a port of Pac Man to the Radio Shack Colour Computer 3.
The key to any good arcade port is authenticity – the game should feel as identical to the real thing as possible. The Atari 2600 port got this famously wrong. Porting to the Colour Computer 3 is easier in theory – with more RAM, a Motorola 6809 CPU running at a higher clock rate, and a more powerful graphics subsystem, fewer compromises need to be made to get the game to run at a playable speed.
The way [Glen] tackled the port is quite handy. [Glen] built a utility that would scrape a disassembled version of the original Pac Man Z80 code, look up the equivalent 6809 CPU instruction, and replace it, while placing the original Z80 code to the side as a comment. Having the original code sitting next to the ported instructions makes debugging much easier.
There was plenty of hand tweaking to be done, and special effort was made to make sure all the data the original code was looking for was accessible at the same addresses as before. There was also a lot of work involved in creating a sprite engine that would reliably display the game video at a playable frame rate.
Overall, the port is highly faithful to the original, with the game code being identical at the CPU level. [Glen] reports that the same patterns used on the arcade machine can be used to complete the mazes on the Colour Computer 3 version, and it faithfully recreates the Level 256 bug as well. It’s an impressive piece of work to create such an authentic port on a home computer from 1986.
For another classic port, but with the temporal vectors flipped, check out Portal 2 on the Apple II.
[deater] readily admits they’re a little behind on what’s new in gaming – only having just gotten around to Valve’s 2007 release of Portal. It’s a popular game, but [deater] didn’t want anyone to miss out on the fun – so set about porting Portal to the Apple II.
The port uses the “hires” mode of the Apple II for the flashy graphics that were state of the art around 1980 or so. It’s not a copy of the full game – only the first and last levels, combined with Jonathan Coulton’s now-classic ending theme, Still Alive. As is to be expected, it’s not a wild, fast paced gaming experience, but a cool use of BASIC to put together a fun tribute to a popular franchise.
It’s a little different to the original – portals can be placed anywhere, for example – but it rings true to the original. Source code and a disk image is provided, so you can try it for yourself – even in this online emulator.
We’re looking forward to the sequel so we can use the post title “Portal 2 Ported To The Apple II, Too”, but until then, check out [deater]’s Apple II web server, also in Applesoft BASIC. Video after the break.
[Piotr] was working on a recent Arduino project when he ran into a problem. He was having trouble getting his Arduino Pro Mini to communicate with an ESP8266 module. He needed a way to snoop on the back and forth serial communications. Since he didn’t have a specialized tool for this task, [Piotr] ended up building his own.
The setup is pretty simple. You start with a standard serial cable containing the TX, RX, DTR, and GND wires. This cable connects the Arduino to the ESP8266 WiFi module. The TX and RX lines are then tapped into. Each wire is routed to the RX pin of two different serial to USB adapters. This way, the data being sent from the Arduino shows up on one COM port and the data being transmitted from the module shows up on the other.
The next piece of the puzzle was coming up with a way to see the data more clearly. [Piotr] could have opened two serial terminals simultaneously, but this wasn’t ideal because it would be difficult to compare the timing of the data. Instead, [Piotr] spent less than an hour writing his own simple serial terminal. This one connects to two COM ports at the same time and prints the data on the same screen. The data from each COM port is displayed in a separate color to make it easy to differentiate. The schematic and source code to this project can be found on [Piotr’s] website.
This hack turns the Sony SmartWatch into a wristwatch. Functionally it’s not all that impressive. But the journey to get to this point represents quite a bit more. This example features an animated tea pot using a 3D rendering engine ported over to the device.
[Federico] started work on the project soon after hearing that Sony had released details about developing for the hardware. He dug into the documentation but soon found it lacked the depth he needed to get a handle on bare metal work. He shelved the project for a while until coming across the Astrosmash project we featured in June. That used a wrapper that allows Arduino sketches to run on the watch. After studying how that’s done he had enough background to port this code.
We’re still waiting to see a really innovative hack for the watch. But we’re glad to see progress with each new proof of concept like this one!
This lovely set of wires lets [Florian] connect stock Super Nintendo controllers to his Raspberry Pi. The IDC connector in the upper left plugs into the GPIO header on the RPi rather than going the route of using an intermediary USB converter.
The setup lets you connect two controllers at once, so you’ll have no trouble going head-to-head on Mario Kart as seen in the clip after the break. The ports themselves were pulled from a pair of SNES extension cables. Since button signals are pushed to the console via a shift register there’s just five wires needed for each (voltage, ground, data, clock, and latch). As far was we know the Raspberry Pi pins are not 5V tolerant so you probably want to add some level conversion to this circuit if you build it yourself.
[Florian] wrote a C program which shifts in data from the controllers and converts it to HID keyboard inputs. This should make it extremely flexible when it comes to emulator setup, and using the technique for different styles of controllers should also be pretty easy.