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.
[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.
[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.
[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!
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.
His other modification is the stuffing of a Microsoft Intellimouse inside of a Logitech Wingman. With the goal of giving the old PS/2 mouse USB capabilities and removing the terrible ball. For those that are asking themselves “why bother? Terrible ergonomics, no scroll wheel, etc.” [Nathan] claims it’s for Quake 2 nostalgia, to each their own we suppose.
I took a little time to look into porting code written for AVR in order to run it on the MSP430 architecture. It’s easier than you think, being mostly small differences like an extra step to enable pull-up resistors. But there is a lot to be learned in order to transition away from using EEPROM.
Since the TI chips don’t have EEPROM you need to use the Info Flash, a topic which I detail in the article linked at the top. This flash memory must be erased before writing because a write operation can only change high bits to low, not the other way around. And an erase operation clears an entire 64 kB segment, not just the bytes you want to write to. It’s different but manageable.