I picked up a Midway-style cabinet that had been converted to a Street Fighter II a few years back. After some inspection I noticed it has previously been a Ms. Pac-Man, which was made apparent by the signature bright blue paint that was over-sprayed onto the inside of the cabinet.

I have a fondness for this style of cabinet, but I already have several in my collection and didn't feel like I needed another. So it sat in the garage for a few years until a friend of mine mentioned he was looking for an arcade for his game room.

He had nostalgia for Donkey Kong Junior; the bright orange paint and the classic artwork, but didn't care so much for the form factor of the Nintendo cabinet. He felt the monitor marquee was too close and that it didn't allow you to really lean into the machine, like a Pac-Man cabinet would. I realized then I had the purpose use for my frankenstein'd Ms. Pac-Man cabinet!

I ended up doing a restoration / conversion combination on the cabinet. This required some custom artwork to be put together as the marquee, monitor bezel, and control panel are all different sizes between the two machines. Instead of a single game, we went with the ArcadeSD game board, which is a great multi-game board, especially for cabinets with a monitor mounted in the vertical position.

It includes a joystick, three buttons, and a trackball and has all the classics: all three Donkey Kongs, Ceneipede, Millipede, Missile Command, Mario Bros, Frogger, Galaga, Ms. Pac-Man, and the list goes on.

It was a really fun and unique build and I'm happy with how it turned out. It's definitely much more appealing than the cramped Street Fighter 2 was!

Timelapse Video

I've put together a timelapse video showing the complete restoration that runs at about 20x speed, which you can find on my YouTube channel.

Parts List

The marquee, monitor bezel, and control panel are all my custom design built in Photopea (a free Photoshop clone) and were printed by Szabo's Arcades.

Artwork

• Szabo's Arcades ▶ https://www.szabosarcades.com/
• Side Art ▶ https://www.szabosarcades.com/products/donkey-kong-jr-side-art
• Bezel ▶ https://www.szabosarcades.com/products/multicade-bezel
• Marquee ▶ https://www.szabosarcades.com/products/multicade-marquee
• Control Panel Overlay ▶ https://www.szabosarcades.com/products/multicade-control-panel-overlay

Electrical

• ArcadeSD PCB ▶ https://www.phoenixarcade.com/products/arcadesd/arcadesd-pcb-us-shipping
• Multicade Upright Harness - JS/Trackball ▶ https://www.arcadeshop.com/i/517/multicade-upright-harness-js-tb.htm
• Happ 20 AMP Switching Power Supply ▶ https://www.arcadeshop.com/i/806/switching-power-supply-20-amp.htm

Controls

• Multicade Årcade Classics Metal Panel ▶ https://www.phoenixarcade.com/products/multicade-arcade-classics/multicade-arcade-classics-metal-panel
• 2¼" Trackball Unit White Ball Atari/Happ ▶ https://www.arcadeshop.com/i/19/2-trackball-unit-white-ball-atari-happ.htm
• Wico Red 8-Way Ball 3.5" Handle Leaf Joystick ▶ https://www.arcadeshop.com/i/1489/wico-3.5-red-ball-handle-joystick.htm
• CLASSX True-Leaf Pro Red Push Buttons ▶ https://groovygamegear.com/webstore/index.php?mainpage=productinfo&products_id=356

Misc

• White Smooth 3/4" T-Molding ▶ https://www.arcadeshop.com/i/866/white-smooth-3-4-t-molding.htm

Manufactured by Gotlieb and released in April of 1992, this pinball version of Mario was pretty unique for its time. I have fond memories of first discovering this game in a Chuck E Cheese entertainment center; it was the first time I had ever heard Mario as a fully voiced video game character. Many people wouldn't experience this until Super Mario 64 was released on the Nintendo 64 some 4 years later.

The music, sound, artwork, and stunning lightshow brought Mario's world to life in a way I had never seen before and it made a big impression on me. So much so that many years later, once I had gotten further into the arcade hobby, I knew I would one day own my own table.

I was lucky enough to find one for sale last year and I jumped at the opportunity. While many seasoned pinball players will dismiss the table as too easy, I'm still having a ton of fun with it.

In this video I just wanted to share some of the modifications I've made to my table. I've included links below the video to all the mods I installed just in case there is a certain one you'd like to check out.

Video

Mods

• Speaker Star Inserts
• LED Strips
• Outhole/Trough Lighting Kit
• Acorn Nuts (Mushroom)
• Acorn Nuts (Bob-omb)
• Acorn Nuts (Castle)
• Hole Protectors
• Pop Bumper LED Discs
• Pirahna Plant
• Action Figures
• Mounting Putty
• Flasher Cover (Question Cube)
• Flasher Cover (Pipes)
• Return Ramp Pipe
• Bowser's Castle
• GameBlades (inner side art)
• Illuminated Flipper Button Kit
• Launcher Button Cover
• Launcher Pipe
• Target Covers
• Coin Reject Buttons
• Pin2dmd
• Pin2dmd community colorization
• ColorDMD

Machine Information

• Pinside
• KLOV

However, the concept of a lock in a JavaScript environment is not as common. This is due to the fact that most JavaScript environments are single threaded. There is no reason to obtain a lock because the code cannot execute simultaneously.

That being said, there are still cases where a lock-like mechanism can be useful: when working with asynchronous code. I've been working on mobile applications written in TypeScript over the last several years and this is scenario that I've ran into several times:

• On app startup, several HTTP API calls need to be made
• Calls are not centralized; they're made from several different locations (screens)
• All API calls have authentication prerequisites (e.g. a cookie or JWT must have been obtained first)

Usually this means that there will be a central function used to handle the authentication logic, lets call it executeApiRequest:

export async function executeApiRequest(apiUrl: string): Promise<Response> {  
  if (!authenticated) {
    // Makes API request and stores token into storage
    await obtainToken();
  }

  // Includes a header with authentication token
  const options = getRequestOptions();

  return fetch(apiUrl, options);
}

Internally, an obtainToken method will be responsible for determining the authentication state, and if a cookie/JWT/etc is needed, it will make an API request to obtain said token. After the token is obtained, the method will issue the original request.

This works great in most cases, However if multiple call sites use the method at the same time (such as app startup), it can result in several API requests to obtain an authentication going out in parallel.

We want to ensure that only a single authentication API request is made, otherwise the user could be issued multiple tokens or experience other undefined behavior.

This is where a lock becomes useful; we want to ensure that only a single asynchronous call to a function can be occurring at a given time. All future calls should wait until the first has resolved and then execute in order after that.

We can achieve this using a list of promises and a bit of logic in a function I've called doWithLock:

export async function doWithLock<T>(lockName: string, task: () => Promise<T>): Promise<T> { ... }  

Which can be used in the original example, like this:

export async function executeApiRequest(apiUrl: string): Promise<Response> {  
  if (!authenticated) {
    // Makes API request and stores token into storage
    await doWithLock('obtainToken', () => obtainToken());
  }

  // Includes a header with authentication token
  const options = getRequestOptions();

  return fetch(apiUrl, options);
}

Now, if several calls to executeApiRequest are made at the same time, they'll all "wait" at the doWithLock call site for the obtainToken function to return. Each additional call will be executed in order.

The helper function is available as a TypeScript source file (with unit tests!) in this gist on GitHub.

After finishing up my Z80/Pac-Man Emulator I thought it would be fun to port it to a game console. Since it was written in C#, the Xbox seemed like a natural fit.

All Xbox One retail units also support a DevMode out of the box, so there would be no need for a jailbreak or hacking around security. I knew the Xbox used UWP apps, so I figured it would be a pretty straightforward port.

I was able to get my emulator running on the Xbox, but I did run into a few hurdles along the way.

While getting a Hello World up and running on an Xbox One is quick and easy using Visual Studio, it assumes you'll be building a GUI app using Windows Presentation Foundation (WPF). This means using XAML to build out screens using controls and widgets. If you want to build a game instead of write an app, this is less than ideal. When building a game you probably want to render to the screen yourself.

It took many hours of Googling to find the correct incantations and hidden settings to get this working, so I figured I would document it here for others trying to accomplish the same thing.

The gist of it is:

• Obtain the source for SDL2 and compile it for the WinRT platform to get a native code SDL2.dll binary
• Use SDL2-CS wrapper to call into the native SDL2 library from C#
• Set the DISABLE_XAML_GENERATED_MAIN compilation flag to prevent the compiler from auto-generating the Main entrypoint
• Remove the *.xaml and *.xaml.cs components
• Create your own Main which delegates to SDL_WinRTRunApp(mainFunction, IntPtr.Zero)
• Write your SDL code to render the screen!

I've documented this in much more detail in the project readme on GitHub. I've also created a pre-packaged starter project which should allow anyone to download, unzip, and open a Visual Studio solution and immediately get started.

Once I finished up my Intel 8080 CPU core for my Space Invaders emulator, I wanted to move onto something a bit more challenging. I knew that the Zilog Z80 CPU was a "cousin" to the 8080; it was largely backwards compatible with the 8080, but also contained a superset of instructions. If I chose to emulate a Z80-based system, I would be able to reuse a large amount of my 8080 core's code.

I looked around for other systems that used the Z80, and there is no shortage!

• Home computers: ZX Spectrum, TRS-80, MSX, Amstrad CPC
• Handhelds: Nintendo Gameboy, Sega GameGear
• Arcades: Pac-Man, Rally X, Dig Dug, Galaga

This was great news; if I built a Z80 emulation core, I could then reuse it for other projects! I decided to start with something simple and well documented: Pac-Man. An additional bonus was that with minor changes, I would also be able to emulate Ms. Pac-Man; all Ms. Pac-Man boards are just Pac-Man boards with a daughterboard installed to modify the original CPU behavior and swap/patch certain ROMs. The story of Ms. Pac-Man it totally worth reading about.

Zilog Z80

I started with a copy of my Space Invaders repository and began stripping out the Space Invaders-specific code. I then got to work implementing the additional instructions present in the Z80. This site offers an interactive and searchable list of opcodes, which was extremely useful. Also, the 2016 version of the Z80 CPU User Manual provided a lot of details.

After implementing the additional instructions, it was time to go back and fix areas of the code that I hadn't completely finished for Space Invaders. I hadn't implemented the auxiliary carry flag and a few other opcodes that Space Invaders didn't use. This StackOverflow post was a great starting point for identifying the differences between the 8080 and Z80.

This part of the project took the longest; I had to rework all the code that set the flags register. As in the last project, writing unit tests along the way was integral to success.

Also like last time, I was able to verify my Z80 implementation by using a diagnostics program written for the original CPU. The Z80 Instruction Exerciser executes every opcode and then compares checksums of memory to checksums generated on actual hardware. Very cool!

I ended up with over 8000 unit test cases, though many of these were permutations of single tests using every register and/or several different memory location offsets.

Video

The Space Invaders video hardware was dead simple; because the screen was black and white, there was one bit per pixel, and the pixel was either on or off. Memory held the array of pixels, and I just needed to draw them using the SDL library.

There are downsides to this, however. Space Invaders included a dedicated bit shift hardware to make this faster.

Pac-Man is in color, of course, so its video hardware is a bit more advanced. It uses tiles and sprites along with pre-defined color palettes. Chris Lomont's Pac-Man Emulation Guide contains a ton of great information on exactly how it works, so I won't recap it all here.

Once I had written the code to draw the tiles, I needed to verify it, but I couldn't yet boot the game. Because the tile drawing code just reads the tile number and palette numbers out of memory, I fired up MAME and got a dump of Pac-Man at a couple of points during the attract screens. I then added this dump to my unit test and visually verified that my code generated a bitmap that matched MAME.

I did something similar to test the sprite hardware; I simply hard-coded the X/Y coordinates and sprite and palette numbers and then ran my render code via a unit test.

You can see the various test results here.

Audio

At this point, I was pretty comfortable emulating a CPU and video hardware, but had no idea how audio worked.

For Space Invaders, I opted not to emulate the analog audio hardware, and instead just played back pre-recorded wav files. This worked fine because the audio in Space Invaders is pretty simple.

In Pac-Man, however, the sound is much richer. There are three audio channels for sound effects, and several different music tracks that play during the intermission sequences.

Again, Chris Lomont's guide was a key resource. However, although I was able to easily implement the behavior of the audio hardware itself, I was at a loss on how to use the audio sample binary data I had to actually play back the audio.

Some Googling eventually led to the article Let there be sound, which begins with the absolute basics and eventually ends with code showing how to play a simple sine wave.

After some trial and error and a lot of static from the speakers, I was finally greeted with a deafening BOOWHAP coin-up sound scared me out of my seat. Pro tip: turn down your speakers before you try out new audio code. 🤣

Debugger

I added upon the interactive debugger from the Space Invaders codebase, which was previously implemented in text-mode inside of a standard console window (e.g. Console.WriteLine and Console.ReadKey). I wanted to make the debugger render inside of an SDL window so that I could have more control over the layout. For example, text can now be rendered in color and single pixels can be plotted. This also makes it easier to implement interactive UI elements, which can be seen in the save and load state menu where the arrows can be used instead of being required to type a full file path.

Bonus: Xbox Port

I came back a few months later and decided to try and port my emulator to a console. I already had the emulator up and running on Windows, Linux, and macOS courtesy of the cross-platform .NET Core runtime, C#, and SDL2. So naturally this was a great fit for a port to the Xbox One via a UWP application.

This led me down a bit of a side-adventure learning about how to get SDL2 running on an Xbox One inside of a UWP app, which was quite interesting. This led to me putting together a starter project template for anyone else who wants to port their SDL2 application to Xbox.

Results

This was an awesome project! It was slightly more challenging than Space Invaders, and taught me the basics of playing audio. With some minor modifications, I was able to run Ms. Pac-Man and homebrew ROMs. With a little more work, I should be able to run other games that run on very similar hardware, such as Rally X and Pengo. And now that I have a fully functioning Z80 core, I can continue on to something more advanced, like the Gameboy!

You can find more details on GitHub. The readme contains a resources section with some links to recommended reading.

Recently, news broke that Quake: Arcade Tournament Edition (Quake A.T.E.) had become playable on the PC after GitHub user mills5 posted a decrypted version of the game's binary executable.

Before I heard this news, I honestly had no idea there was a version of Quake made for the arcades! My curiosity was immediately piqued, and I began to look for information about the cabinet.

This blog has some excellent information, and you should check it out if you're interested in the details (edit: this ArsTechnica article is even better). But the gist is that a company named Lazer-Tron developed an arcade platform known as the Quantum3D Quicksilver Arcade PC, essentially a Pentium II computer with a proprietary I/O card and a 3dfx Voodoo video card.

Although a dump of the arcade's hard drive has existed for a while, the game's executable was encrypted and required a security dongle, so nobody has been able to run it. Now that the unencrypted executable is available, the game can be run on modern Windows PCs using the game asset files from the quakeat.chd hard disk image, which comes from MAME.

Here're a couple of recordings I took while running the game on a Windows 7 VM showing the attract mode and service menus.

Booting the HDD

Although MAME doesn't currently run the game, I was curious to see if I could boot the hard drive image on an x86 virtual machine. After all, it's just a customized version of Windows 95 OSR2. I used MAME's chdman tool to write the image to a virtual disk, which I was then able to mount on a Windows 7 virtual machine.

Once I was able to confirm I could mount and read the FAT32 file system, I unmounted the disk and created a new virtual machine on my ESXi server. I attached the disk to the new VM, crossed my fingers, and fired it up. Sure enough, it booted! After a bit of ScanDisk and Add New Hardware wizard action, I was dropped into the Windows 95 desktop!

Below are a list of screenshots I took that show all kinds of interesting details: Quake config files, custom config tools, OS customizations, TweakUI settings, bookkeeping data, and more! A bit of digital archeology, if you will. Fascinating stuff!

Using the decrypted executable to launch the game inside of the VM works, but because the VM currently has a 16-color, generic VGA adapter, you can't see much.

Even though I grew up with 90's style arcade cabinets, I've always had a soft spot for the "golden age"-era Midway cabinets, which housed games like Galaga, Galaxian, and Pac-Man. When a Ms. Pac-Man cabinet popped up on Craigslist, I jumped at the opportunity to pick it up.

Once I saw the cabinet in person, I noticed several things that indicated it wasn't, in fact, an original Ms. Pac-Man cabinet. The most obvious were the Pac-Man bezel and control panel; someone had painted over the original artwork with the signature blue color and added a Ms. Pac-Man marquee. The signature almost-square Midway coin door had been replaced with an over-under coin door. To accommodate the size of this different coin door, an additional piece of 3/4" plywood had been placed over the front. The cabinet had also seen a bit of water damage, and had extra reinforcements inside and on the base.

Originally, I was planning to restore the cabinet as a Ms. Pac-Man, which has one of my most favorite art designs. However, a few months later I was able to score an original Ms. Pac-Man cocktail cabinet, so there was no point in having two Ms. Pacs.

The 3/4" plywood that had been slapped on front had to stay. It would have been difficult to remove, and given the water damage, it was also probably a makeshift reinforcement for the cabinet body. For the next few months, the cabinet sat in my garage, and then I stumbled upon an awesome Multicade artwork package by Phoenix Arcade. I've never been a fan of Multicade art designs before; they always have a weird mix of modern and retro character designs and artwork, and they just don't look quite right to me. This art set, however, was perfect: exclusively original character artwork and pixel art with an 80's Tron aesthetic, and UV reactive to boot! After finding this, I decided to restore the cabinet as a Multicade.

Cabinet Prep

As always, I started by stripping down and removing all parts. This didn't take too long because the machine had already been mostly stripped; it had no CRT, PCB, or power supply. What was left inside was a rats' nest, figuratively and literally! That was pretty gross, and required a lot of cleaning. The bottom of the cabinet still looks a little dirty due to the water damage, but it's better than before. Next came general clean-up and sanding down the surfaces. Once everything was relatively clean and smoothed, I began to fix chipped areas with wood filler.

As this point I agonized over the color for the cabinet body. I wanted something to match the artwork well, but not take away from it when lit by UV light. I knew I wanted something darker, but definitely not straight black. I eventually decided on the color Midnight Blue in an enamel base. It turned out wonderful; it meshes well with the background and secondary blue colors in the artwork, but isn't overbearing.

The coin door needed a little work. I went with my go-to Rust-oleum enamel black spray paint for the body. The coin mechs were also totally seized up, so needed to be completely disassembled and cleaned.

Control Panel

The Phoenix Arcade Multicade package included a nice metal control panel that is an exact fit for Midway cabinets. It includes precut holes for a joystick, three action buttons, a trackball, and two player start buttons. I ended up making custom plywood inserts for the underside so I could utilize the cabinet's original latches and pegs to hold the control panel in place.

The Multicade package also included CPO overlay graphics matching the rest of the artwork.

All the new controls use leaf switches, which I've come to prefer over microswitches for their quietness and "softer" feel, which matches the feel of cabinets from that era.

The joystick is a Wico 4-Way with a yellow ball top. The trackball is the 2¼" Atari/Happ unit. All of these parts are from ArcadeShop.

The action buttons are the CLASSX True-Leaf Pro line from GroovyGameGear.

The game board I planned to use would support blinking start buttons, so I got two of the Electric ICE 2 pushbuttons, again from GroovyGameGear. When enough credits are deposited, the 1 player or 2 player buttons blink!

Marquee and T-Molding

The Phoenix Arcade Multicade package included a UV reactive marquee, so I decided to throw in two blacklight bulbs instead of regular bulbs. Although it's not very noticeable in daylight, it lights up great at night.

In keeping with the UV reactive theme, I chose green UV reactive T-molding from ArcadeShop. I think I would have preferred white T-molding, but I couldn't find any that was UV reactive. It does look great under a blacklight.

Monitor

I had been saving one last NOS CRT for this project. A couple years ago, I was lucky enough to find three new-in-box 21" NOS CRTs (WEI-YA M2621H) on eBay. I used one in my Multi-Williams cabinet and another in my Galaxian, and this was the last of the three.

I couldn't be happier with these monitors. My only regret is that I didn't order a couple more! The colors are fantastic, and the onboard isolation transformer means that I don't need a large "power board" at the bottom of the cabinet.

I built a custom monitor mount from plywood, identical to the one I made for my Galaxian cabinet, and a custom bezel mask from presentation board from Michaels.

Game Board

I knew I didn't want to go with a generic 60-in-1 board, nor a Raspberry Pi or MAME setup. I've tried both in the past and I still prefer native hardware. In this case I found a good trade-off: the ArcadeSD board.

Although this is an emulation board, it is best in class and far better than the 60-in-1's I've tried in the past. This board does have an FPGA on board, but I believe it's only used for generating the video signal.

The board can run around 90 games, though I pruned the list for this cabinet down to about 30 of my favorites. It also supports several trackball games, including Missile Command, Centipede, Liberator, Arkanoid, and Crystal Castles.

Another unique feature of this board is its ability to run a few horizontal games on a vertical screen, such as Mario Bros., Super Mario Bros. VS, Excitebike, Missile Command, and Tapper. A full list of games is available here.

The menu system is best in class as well, with beautiful game logos and screenshots or icons. I can't recommend this board enough.

For wiring, the JAMMA harness I wanted to use was out of stock, and I was impatient, so I went with a cheap/generic JAMMA harness. I can tell you that I will never skimp on a harness again. The one I got was super short, poorly soldered (wires came off of the connector a couple times), and used an insufficient wire gauge for the 5V lines. Lesson learned: if you're spending under 30 bucks for a JAMMA harness, you're gonna have a bad time. Stick with the ones in the $50+ range and you'll be much happier. In the end I got it working, but it took many hours of re-soldering and troubleshooting.

For power, I went with my standby: the HAPP Pro from ArcadeShop. I like this power supply because it has an AC outlet for the CRT and remote power switch capability, which I use to power the machine on/off via a DPST toggle switch on the top of the cabinet.

End Result

Like every project I finish, this is my new favorite! It looks great under the blacklights in the game room. I love the artwork! The game line-up is awesome! It has blinking start buttons! It can play trackball games! I love it!!!

I'm working on converting my Galaxian MAME cabinet back into an OG cabinet with an original PCB and CRT. In this cabinet, I will be using a JAMMA switcher to switch between Galaxian and Galaga.

An original Galaxian board expects to receive 7 volts AC and has hardware on the PCB to convert this into 5 volts DC. However, since I am using a JAMMA harness and power supply with my JAMMA switcher, I have 5 volts DC supplied by a switching power supply. To allow the Galaxian board to work with my JAMMA setup, I needed to modify my Galaxian PCB to accept 5 volts DC directly.

Paul Swan has written an excellent guide on how to accomplish this, which can be found on the internet in several locations, including Mike's Arcade, Marco's Arcade, and the UK VAC forums.

However, as of this post, none of those sources include pictures. The instructions are straightforward, but when you have a vintage PCB in your possession and are about to take a soldering iron to it, it's a bit more comforting to have some pictures to confirm you're following the steps correctly. I put this post together to provide some pictures for reference.

Again, I didn't write these instructions, but I can confirm they work. If you want more information on the mechanics, the aforementioned UK VAC forums post goes into more detail.

With that...let's get started! To perform this modification you'll need:

• Wire cutters
• Wire (solid, not stranded)
• Soldering iron
• Solder

Here is a list of the components you'll need to remove from the board using the wire cutters. A few of the components will need to be replaced with a jumper wire. In addition to part number, the board quadrant is also listed for each part below.

Finally, you may need a wire link between the edge connector pair 5,E to 4,D. I did not need this connector because the JAMMA adapter I used already bridged these connections.

On to the pictures! The third picture is annotated with each of the part IDs.

I really enjoyed the process of building my CHIP-8 emulator, so after I finished I immediately started looking for another emulator project.

The general consensus on r/emudev and the EmuTalk Forums seemed to point to the 1978 arcade game: Space Invaders. This was perfect for me since it also overlapped my other hobby: arcade machine restoration.

The getting started phase went much quicker than my first emulator since I was able to re-use several components from my CHIP-8's C# codebase: the command line interface program, the SDL GUI program, and the unit test runner. I did take some time to reorganize the project structure.

TL;DR: Skip to the Results section for a video clip and link to the source code.

Intel 8080 CPU

In my CHIP-8 emulator I only had a single project which encompassed the CLI program, GUI, and emulator. This led to tightly coupled modules. While this was fine for a small emulator, I knew this wouldn't work for something larger.

Space Invaders uses an Intel 8080 CPU running at 2 MHz along with some of its own specific hardware. I did all the work on the CPU core in its own module to keep it separate from the rest of the game's hardware. This should allow me to re-use much of my CPU core code for future emulation projects that use the Intel 8080 or it's cousin the Zilog Z80.

An aside: One of my favorite parts of this project was checking out the Intel 8080 Assembly Language Programmers Manual. This manual explains how each opcode works at the byte level and was my main reference. This manual was fascinating because it illustrates how CPUs in this era were simple and understandable. Today's modern CPUs are so complex that even if you write assembly language for them it is not what runs on the bare metal (see: microcode) and they even run entire operating systems in their firmware (the MINIX operating system is embedded in Intel CPUs Management Engine for example ).

One major difference from the CHIP-8 was that CPU speed and the number of cycles executed was important. I needed to count the number of cycles per instruction so that I could throttle the emulation loop to approximately 2 MHz so the game would run at the correct speed.

Additionally, the Intel 8080 CPU has interrupts which can temporarily pause CPU execution in order to temporarily run other opcodes before resuming. Space Invaders fires two different interrupts at 60 Hz; once when the CRT's electron beam is approximately half way down the screen and the other when the beam is at the end (which is also known as VBLANK). We can estimate when these interrupts should occur based on the number of cycles executed.

Audio, video, and shift hardware

Another interesting aspect was seeing how the Space Invaders PCB connected the CPU to other pieces of hardware. The IN and OUT instructions can be used to read and read bits from other "devices". In this case the code "reads" the state of the buttons (pressed or not pressed) and "writes" bits to tell the analog audio hardware when to play sounds.

In this case I didn't attempt to emulate the analog audio hardware, and up until recently even real emulators like MAME didn't either. From what I understand it is computationally expensive to emulate analog hardware, and simply playing back WAV samples when needed is close enough.

Graphics are handled by writing bits into a specific region of memory. In order to place sprites, frequent bit shifting is needed. Unfortunately the 8080 doesn't have opcodes for shifting, so Space Invaders includes a dedicated shift register. This pieces of hardware is accessible via the IN and OUT instructions as well.

Verifying Opcode Behavior

As with the CHIP-8 emulator, building unit tests for each opcode at the same time as implementing the opcode was instrumental for success. It's much easier to test each opcode in isolation than trying to track down bugs when the entire game ROM is loaded and running.

While this saved a ton of time, it didn't catch 100% of the bugs of course. Some of my unit tests made assumptions that weren't correct. Also some of my unit tests were just wrong. I used two additional approaches to verify my opcode behavior and track down bugs: integration testing and adding an interactive debugger.

While unit tests verify the behavior of an individual opcode is correct, bugs can still be possible when you have opcodes that interact. For catching these scenarios I used an integration test by leveraging this CPU diagnostics program for the 8080/8085. By assembling and running this program against my CPU I was able to verify it was mostly correct.

The last few bugs I had to track down weren't caught by either my unit tests or the integration test. There were a couple of crashes that occurred consistently during the game's attract mode when the CPU attempted to access memory locations far outside the game's 8K of addressable memory space. Using my IDEs debugger was helpful in tracking down how the illegal memory access occurred, it was nearly impossible to see which combinations of opcodes and how they interacted that resulted in the wrong memory address being calculated. At this pointed I needed a more specialized debugging tool.

Interactive Debugging

I wrote an interactive debugger that would allow me to debug at a higher level. Instead of stepping over lines of C# code that implemented the 8080 opcodes, I needed to step over individual opcodes and verify register and memory values, just as if I was debugging an 8080 program. So I incorporated the zasm disassmebler and built an interactive debugger.

From here I could set breakpoints, inspect register and memory values, single step over opcodes, save and restore CPU state, and view a history of opcode execution. I also implemented a rewind feature so that once I got to the problematic opcode I could them step backwards over opcodes to see how I got there.

This allowed me to track down an issue with the interaction between two opcodes (CALL and RET) which the unit tests and diagnostics program did not catch.

Results

Space Invaders is an excellent second step after finishing a CHIP-8 emulator. It adds a few new concepts (timing, interrupts, external hardware) but nothing too hard. I'm also hoping that I can re-use much of my CPU core for my next project since the Intel 8080 is very close to the Zilog Z80 (perhaps Ms. Pac-Man, Galaga, or even the Gameboy).

You can find more details on GitHub. The readme contains a resources section with some links for recommended reading.

I feel quite a bit of nostalgia for a few specific arcade machines that were in my local Round Table pizza when I was growing up: The 4-player beat-em-up Teenage Mutant Ninja Turtles, the 3-player racing game Off Road, the super cool 4-game Neo-Geo, and the cocktail cabinet version of Ms. Pac-Man.

I remember that last one most vividly. Being able to sit and set down your drink while you took a break from the upright machines was such a nice change. This was the cabinet that first got me interested in Ms. Pac-Man and Arkanoid, among other games.

I purchased a flatpack cocktail cabinet kit from Haruman's Customs a couple years ago, which took a backseat to other arcade projects. But recently, I finally had some time to tackle this project.

Cabinet Body

Haruman's kit comes in melamine, MDF, and baltic birch plywood. I went with the birch, which has a nice natural look, and stained it Dark Walnut with several finishing coats of polyurethane. This was my first time working with an oil-based stain, and although it involved a lot of work and clean-up, I couldn't be more pleased with the results.

I also added leg levelers from RetroArcade.us.

Monitor

The kit is built specifically for the Dell 2001/2007FP LCD. This is one of the largest 4:3 LCDs available and it has very good left/right viewing angles, which is important on a cocktail cabinet (you'll be viewing the LCD from the sides when it's mounted in portrait orientation). I went with the 2001FP version because that's what I was able to find on eBay for a decent price.

Unfortunately, the kit's mounts weren't big enough for my monitor, even after removing the plastic housing from the screen. I had to improvise a bit with some metal brackets. I also removed the LCD's front panel PCB and mounted it on the bottom to prevent the kit's stop wood panel from depressing the buttons.

Once I had mounted the LCD, I realized I had forgotten to paint the exposed plywood border (oops), so I masked off the LCD panel and did a quick coat of black paint.

Cabinet Hardware

The cabinet kit is also pre-cut for several other commonly sized pieces of hardware, such as the speaker, ventilation, coin doors, and glass top.

I got the speaker and speaker/ventilation grills from Arcadeshop.

I went with this coin door from Twisted Quarter. Although the dimensions match, the corners of the door were more rounded than those of the pre-cut hole in the kit, which left small gaps at the corners. I was able to position the coin door such that the gaps aren't visible on the top corners, but they are still slightly visible on the bottom.

The kit's top is cut specifically for the standard Bally Midway glass, so I used this replacement by RetroArcade.us. Another hiccup here was the clips used to hold the glass in place. Haruman's kit comes with clips, which are listed on the website as "ABS black cocktail glass clips (pressure fit, no screws needed)." Unfortunately, they didn't stay on at all; they fell off easily when touched. I wanted to use a set of the metal cocktail glass clips that are used on authentic cocktail cabinets, but those cabinets are built with 3/4" plywood, whereas Haruman's kit uses 1/2" plywood, so that wouldn't work. Ultimately, I had to use screws on the underside of the cabinet to secure the kit's plastic clips in place, which causes them to bow a bit.

Control Panels

The kit's control panels come pre-cut for a joystick and three buttons, with an additional two buttons on one side for the start buttons. I attached the panels with metal brackets and wood glue to add stability.

I used piano hinges to attach the control panel tops to the body, to allow easy access underneath. I couldn't find any piano hinges that were close in size, so I bought a much longer one and cut it with a Dremel.

I used Rust-Oleum enamel spray to add several coats to the control panel tops. It came out looking very shiny, and seems pretty resistant to scratches and wear so far.

By far the most frustrating part of the build was attaching the control panel tops to the cabinet. The kit's instructions suggest using Velcro or magnets, but I was very doubtful that would work well. When playing games, people put a lot of weight on the panels pulling the joysticks (think trying to outrun ghosts in Pac-Man), and I just didn't think Velco or magnets would hold up to the force--or if they did, there would likely be lots of wobble on the panel. I decided to look for my own solution.

I wanted something like the system used by real cocktail cabinets, which have clamp clips accessible on the inside by reaching through the coin door. This keeps the control panels tops extremely tight (no wobbling), and prevents the control panels from being opened unless you have the key to the coin door.

After several trials, eventually I ended up using chest catch latches. I had to cut some shims from the extra wood that came with the kit so that the latches were at the correct height. This ended up working really well; the panels don't wiggle at all and are easy to unlatch from the inside.

As for the joysticks and buttons, I used the set from this kit by RetroArcade.us.

Wiring and Game Board

The kit came with a fused power switch that uses an IEC C16 connector (standard PC power cable). I connected the switch outlet to a power strip on the inside, which powers the game board, audio amplifier, and monitor.

I used a switching power supply and JAMMA harness from this kit by RetroArcade.us.

The audio amplifier wasn't strictly necessary, but I like to be able to easily adjust the volume with a knob, instead of having to go into the game board's firmware menu. I used the Lepy LP-2020A amplifier.

There wasn't enough room behind the control panel plexiglass for any bulbs for backlighting, so used some LED strips with adhesive backing (similar to these) and stuck them around the plexiglass edges.

As for the game board, I went with a generic 60-in-1 JAMMA board.

Everything is accessible from a side door, which opens on a piano hinge. It is held on with these latches, which can be opened by reaching through the coin door.

Results

Overall, I am thrilled with this build. I couldn't be happier with how the finish on the baltic birch plywood turned out. The staining process was messy and time-consuming, but it looks so much better than black melamine, it was worth the extra time and clean-up.

Although I was faced with several gotcha's, I would absolutely recommend Haruman's cocktail cabinet kit, as long as you know going in that it isn't a turn-key solution and will require a bit of improvisation.

I'm in the midst of upgrading a Cordova app to use Capacitor, but keeping the original application code, which was built in TypeScript and uses Ionic 1.x. It uses my Ionic/TypeScript Starter Project project template.

This template was created a few years back and uses TypeScript namespaces (previously known as "internal modules") as opposed to the more recent module format.

This essentially means that instead of using the more modern ES6 import directive, everything is accessible via namespaces in a single bundle. This is problematic when you want to use TypeScript definitions, which are written in the modern module format, for Capacitor.

I threw together some TypeScript definitions for Capacitor that are compatible with TypeScript projects using namespaces instead of modules. They're up on GitHub as a jumping-off point for others who might want to run their older TypeScript projects in Capacitor.

Over the years, emulators have allowed me to play rare games that would otherwise cost exorbitant amounts of money on eBay, or re-experience titles I already own without dusting off my original hardware. Emulators also allow us to archive and preserve old games for future generations as older hardware fails and/or becomes more scarce.

Beyond playing games, I've always had a technical fascination with emulators as well. I knew the basics of how they worked from my computer architecture and assembly language classes, but even so, they were still shrouded in mystery. I've always wanted to write my own emulator, but sitting down to read how a particular piece of hardware works, or even reading existing emulator code, can be overwhelming.

When I came across an article on HackerNews talking about the CHIP-8, and how it was an excellent choice for writing your first emulator, I decided to finally tackle this project.

A lot has been written about the CHIP-8, so I won't go into a lot of detail here. Consider this the ClifNotes version.

Technically, the CHIP-8 wasn't actually a hardware device. Instead, it was an interpreted programming language hobbyist computer, like the COSMAC VIP, from the mid-70s. It allowed software (mostly games) to be written in an intermediary opcode format and then interpreted in different hardware architectures.

However, language is a bit generous in this case. Instead of writing in a high-level language like Java, you instead type out 16-byte opcodes on a hexadecimal keyboard. Because you're still very low in the hardware stack, it's similar to writing an emulator for a piece of hardware: you have a program counter, registers, a stack, etc. This makes it a great candidate for a first emulation project.

Overall, this was an extremely rewarding project, and I would highly recommend anyone who's thought about doing this to check out the article I linked earlier. It lays the groundwork without giving too much away.

I wrote my emulator and assembler in C# targeting the cross-platform .NET Core runtime. It uses SDL2 for the GUI.

You can find more details on GitHub. The readme contains a resources section with some links for recommended reading.

On Christmas eve, as we were driving to visit family, I was browsing Craigslist and stumbled upon an almost comical posting:

Free arcade machine, must go today, need to put up Christmas tree

I didn't realize people put up their Christmas tree the day before Christmas, but who was I to complain? It's hard to beat a free arcade machine. We immediately made a detour to pick up a dolly at the closest hardware store, then headed over to the address to pick up the cabinet.

The cabinet was a Shinobi in rough shape: quite worn, and with kids' stickers all over it. Although nothing would appear on the screen, the machine did power up and play attract mode sound effects, which indicated that the PCB was working. I wasn't surprised the CRT didn't work; there was a severe, hard-to-miss burn mark in the center of the tube.

The cabinet sat in my garage for a year or two, partly because I was finishing up other projects, and partly because I wasn't sure what the cabinet had been originally. But one day, while reading Where did all the Defenders go? over on The Arcade Blogger, I was stunned to find a picture of a Defender-to-Shinobi cabinet that looked almost identical to mine.

Having never played Defender, I wasn't sure that I wanted a dedicated Defender cabinet. However, Robotron 2048, my favorite game, is also made by Williams. A bit of searching indicated that Williams made a multi-game cabinet. That seemed like a worthy fit to me, so I got to work!

Cabinet Prep

First things first: the cabinet needed to be stripped of parts and sanded down. The leg levelers had been removed, resulting in a fair bit of damage around the bottom edges. I cut back the loose pieces and filled it all in with wood filler. After another round of sanding, it was ready for primer and paint.

On previous cabinets, I've used vinyl graphics. But for this cabinet, I wanted to try something different: stencils! The first step was a base coat of paint. I used Rust-Oleum Satin black flat, which in retrospect was a mistake: the flat paint scuffs way too easily. I would recommend a gloss or at least a semi-gloss paint for the base coat. I worked this out in the end by applying a clear coat of Krylon Satin Crystal Clear over the finished stencils, after one final wipe down with tack cloth.

Stencils

I got my amazing Multi-Williams stencils from This Old Game. The stencil set for my cabinet has two colors: red and yellow. There were two stencil sets for each side and the front coin door, a total of six altogether.

I had never used stencils prior to this, but the process was very simple. The stencils were shipped in a cardboard tube, so the first step was to lay them out flat and give them time to uncurl. My wife helped me position the first stencils on each side of the cabinet using painters tape. After they were positioned, we peeled back the inner backing layer and used a squeegee to apply the stencil to the cabinet. Once applied, the entire cabinet was masked off with painters plastic and painted with Krylon Gloss Sunburst Yellow spray paint.

Once dry, we slowly peeled back and removed the first stencil layer. Then we applied the second layer over top of the first for the second color. Another round of masking had to occur before we were ready for the second color, Krylon Gloss Banner Red.

The coin door also received a coat of Rust-Oleum Hammered Black, which helps cover its minor dents and scrapes.

Though it was my first time working with stencils, I was very happy with the outcome. It isn't perfect; if you look closely, you can see spots where the paint ran or edges that aren't perfectly straight. However, this lends the cabinet a certain air of authenticity; during the arcade heyday, when these cabinets were churned out of the factories at a blistering pace, many were painted with stencil sets instead of printed graphics. You'll see the same imperfections on authentic cabinets as well.

If you are considering stencils, I'd highly recommend it. The paint colors pop in a way they do not on printed vinyl graphics. This Old Game makes a great set of stencils that apply and remove very easily.

Control Panel

To prepare the control panel, I first needed to remove the existing hardware and overlay. It's surprising how well the adhesive holds up after all this time; a simple pull won't budge it. But with a little heat from a hairdryer, it peels off quickly. Underneath, you can see the original holes for the Defender layout.

The Multi-Williams layout I chose is very similar to the Defender layout; I only needed to add three new holes. I used a drill press to do this. I also used a little wood filler to fill in a pitted area on the top right of the board.

The overlay art I used was about an eighth of an inch shorter than the original, leaving some exposed wood. A quick spray of black Rust-Oleum covered it right up.

The overlay and plexiglass are from This Old Game.

To reduce noise, I went with leaf switches on the buttons and joysticks instead of microswitches. The joysticks are the Wico 8-Way from Arcadeshop and the buttons are the CLASSIX in the True-Leaf Pro configuration from GroovyGameGear.

I wired everything up and tested the inputs on the workbench before re-installing the control panel.

Marquee and T-Molding

Lately, I've been using LEDs instead of fluorescent lights for my cabinet marquees. Unfortunately, the NovaMatrix 2 is no longer in production, so I went with a generic roll of 12v LEDs.

The marquee is from Escape Pod and the T-Molding is from Arcadeshop.

Monitor

I was lucky enough to find a seller on Ebay with a lot of several brand new in box (old stock) 21" CGA CRTs. Though they weren't an exact fit for Defender's 19" screen, I couldn't pass up brand new, never used CRTs. It's not often you get to peel the protective plastic from a CRT and fire it up for the first time, especially since CRTs have been out of production since the early '00s.

Specifically, the monitor is a WEI-YA M2621H. Powering it on for the first time was a treat. The colors are amazing. I can't wait to install CRTs in a couple of my existing cabinets that currently have LCDs.

One issue arose from the use of a 21" screen instead of a 19": all the available existing bezels have artwork created for the 19" screen, and thus wouldn't work. Instead, I went with plain smoked plexiglass, which actually looks good considering how busy the artwork on the marquee and control panel is.

Finally, I made a custom bezel using presentation board from Michaels.

Game Board

I wanted to avoid software emulation for this cabinet. Running PC hardware with a full operating system and MAME sometimes seems like overkill. In this case, I was able to use an FPGA PCB that runs the original ROMs without any software emulation. The wSYSFPGA by JROK is absolutely amazing. Instant boot-up, just like the arcade hardware. An FPGA board is as close to the original hardware you can get without buying an original PCB.

I used a Super JAMMA wiring harness and the HAPP Pro power supply from Arcadeshop.

End Result

I am extremely pleased with this build. This project included several firsts for me: stencils instead of vinyl artwork, a brand-new CRT instead of an LCD, and an FPGA instead of software emulation.

I suspect I will soon be retrofitting my existing cabinets to have CRTs and FPGAs as well!

I've always been drawn to Nintendo's cabinet style, so when I saw a Nintendo cabinet on Craigslist only an hour's drive away, I jumped at the chance to get it.

The cabinet I picked up was orange. It had been converted to Arkanoid and had a beautiful original Sanyo CRT with no burn in. The monitor bezel was for Donkey Kong Jr., though it had been flipped backwards so the artwork was hidden.

There were two ID plates on the back of the cabinet: DJR1-UP and DKC1-UP-US. The former was obviously for Donkey Kong Jr. (which matched the bezel), and at the time I assumed the latter was for Donkey Kong, so I began the project as a plain Donkey Kong restoration.

It wasn't until well into the project that I found this list, which indicates that DKC was for Donkey Kong 3. That means the cabinet was probably a Jr. that was converted to a DK3, or visa versa.

I'm a little disappointed that I didn't find this out before I started the project, but at least it's still in the DK family.

Base

The cabinet was in pretty good condition, but there were some rough areas I wanted to take care of first.

Nintendo cabinets have two wheels in back so you can tilt the cabinet up and taxi it around easily. The cabinet rests on a board in front, which can get quite beaten up over time. I decided to build a new base after watching this video by The Canadian Arcade. My base is much simpler, but it gets the job done.

Marquee Lighting

It's always so satisfying to see a cabinet's marquee light up, so I took care of that next. I used the NovaMatrix Linx 2 marquee LED strips from GroovyGameGear. I used a previous version of this same product on my Galaxian restoration, and I was very happy with it. They are low voltage, so you can run them directly off of a 12v DC line.

Cabinet Touch-ups

As is normal with cabinets that have seen a lot of moves, this one had several dings that needed attention, especially around the edges. I used Elmer's Wood Filler to fill the missing chunks, then sanded down the areas once they dried to make sure they were smooth.

I needed to make sure everything was especially smooth because I decided to use vinyl siding instead of paint. I chose vinyl because it worked out pretty well on my Galaxian cabinet; I went with the blue vinyl kit from This Old Game.

Coin Door

The coin door had taken a lot of abuse. Normally this can be solved by a can of Rust-Oleum Hammered Metal Finish Spray Paint, but in this case, the damage was more than just cosmetic. The door itself was so bent out of shape it would barely close.

I decided to use a reproduction coin door from a member of the KLOV forums. I also got new coin mech face kits from Mike's Arcade.

Graphics

GameOnGraphix has done great work for me in the past, so I went with them again for the side art as well as the marquee.

The monitor bezel is from Mike's Arcade, which has a great selection of Nintendo parts.

I found out the hard way that some Nintendo cabinets, like this one, need special T-molding with the middle groove offset instead of centered. Fortunately, I was eventually able to find Nintendo "True Offset" T-molding from Chomping Quarters.

Control Panel

There is a lot of empty space on a Donkey Kong control panel, and I had planned to build a custom one from scratch so I could include a small trackball and spinner in addition to a joystick with a few extra buttons. While looking for parts for that build, I came across a reproduction control panel on Mike's Arcade. I knew I wouldn't be able to build a custom panel for cheaper, so I went with the Mike's product for now. I can always build a custom panel to swap out in future if I want.

For the control interface, I went with a Mini-Pac from Ultimarc and one of their pre-made wiring harnesses. I hung onto the original wiring harness that came with the control panel, though, so I can use it if I ever decide to install an original Donkey Kong PCB.

Monitor

The cabinet came with an original Sanyo CRT monitor that was in excellent condition. No visible burn in at all! I decided to get the ArcadeVGA from Ultimarc, which I'd heard good things about, so I could interface the monitor directly with the PC. This is a PCI Express video card that has a custom firmware that allows the card to output the special 15kHZ signal that arcade monitors require. I used Ultimarc's VGA monitor cable adapter to connect the CRT to the video card.

PC & Wiring

I decided to go with an Intel Atom 330 Mini-ITX motherboard mounted using a LogicSupply CT100 open-frame mount. This mount is nice because it also has spots for the PC's power supply and SSD.

The single speaker audio is driven by a Lepy LP-2020A mini amplifier. I chose this because it has an integrated volume knob that I can access via the coin door.

To turn the cabinet on/off, I added a standard arcade button to the rear top of the machine, which connects via a custom-built cable to the power-on pin of the PC motherboard. When the PC turns on, it pulls power from a smart power strip that turns on the rest of the outlets, powering on the monitor. Another single press elegantly shuts down the PC, then turns off the monitor.

Software

The PC runs Windows 8.1 and a custom build of MAME v0.197 to disable "nag" screens.

The machine has 11 games on it, and it boots directly into Donkey Kong when powered on.

Using a button key combination, the user can exit to a menu to select a different game. I couldn't find an existing menu system that looked like software from the cabinet's era, so I wrote my own in C#, and have made the source available on GitHub.

As a bonus, I added a modern game: Downwell. This is an excellent arcade-style platformer that was released in 2015, with simple yet addictive gameplay indicative of the golden age of arcade games. It has simple pixel art and color palettes and requires only three buttons (left, right, jump/shoot), so it was a perfect fit for the cabinet. It looks amazing on the CRT.

End Result

I'm very happy with the way this cabinet turned out. The original CRT is beautiful, and running the games at their original resolution and being able to play a modern game on the hardware is novel.

In the future, I may add original Donkey Kong and/or Donkey Kong Jr. PCBs. Or maybe I'll even go back and build a custom control panel.

A full gallery of pictures showing the restoration process is available via Imgur.

These hooks can run on specific events (before_platform_add, after_prepare, etc.) to execute your arbitrary code. As your build hooks get more complex, you may find that you want to attach a debugger and step through your script. Because build hooks are generally written in JavaScript to be executed in Node.js, this should be as simple as using the Node --inspect parameter. However, there are two different ways to write build scripts, and only one of these can be used in this way.

Legacy Build Hooks

The legacy build hook is easiest method for getting started. To build one, you simply place a file in a subdirectory of the hooks directory of your Cordova project, with the subdirectory name matching the build event you want to hook. For example, to hook the after_prepare event, you would add a file with the following path:

hooks/after_prepare/01_your_script.extension  

This script is executed by Cordova as a shell script. Parameters are passed into this script as environment variables.

This complicates things a bit for cross-platform development. On Windows, your script needs to be something the operating system can execute (e.g., a batch file with extension .bat or .cmd). On Unix-y systems, this would be a shell script with its execute bit set (e.g., chmod +x) and a shebang header:

#!/bin/sh
# Your script here

Thus, the first reason to avoid legacy build hooks is that they make targeting multi-platform development double the effort; you'll need an equivalent script for both Windows and *nix.

Even if you aren't targeting multi-platform development, the aforementioned problem is still introduced when attempting to debug: even if your script is written in JavaScript using #!/usr/bin/env node to indicate it should be executed in Node.js, it will be executed out of process by Cordova. This means that even though you may be able to attach to the Node process running Cordova, the build hook script is in a separate Node process, so your breakpoint will never be hit.

Before you can debug your scripts, you'll need to convert them to the modern format.

Modern Build Hooks

The modern build hook format is JavaScript, without a shebang header. This is because the hooks are not executed as shell scripts, but instead loaded and executed by Cordova in the same Node.js process. If you have legacy build scripts written in JavaScript as shell scripts, you'll need to remove the shebang header and convert them to the new format.

Let's look at converting a script from the legacy format to the modern one. This trivial script simply writes out the names of the Cordova plugins that are installed when executed.

Legacy script:

#!/usr/bin/env node

console.log("Installed plugins are: " + CORDOVA_PLUGINS);  

Modern script:

module.exports = function (context) {  
    console.log("Installed plugins are: " + context.opts.cordova.plugins.toString());
}

In addition to removing the shebang header, you need to wrap your script in a function that is exported. Your function will receive a context object as a way of passing parameters, instead of passing them via environment variables.

One final change is needed: previously, Cordova enumerated the hook directory's subdirectories looking for shell scripts. Now that the script is no longer a shell script, you need to add an entry in config.xml (or plugin.xml, if you are writing a hook for a plugin) to tell Cordova about the hook:

<hook type="after_prepare" src="hooks/your_script.js" />  

Once you've converted your scripts to the new format, you're ready to debug them!

Debugging Your Hook

It's as simple as executing Cordova using Node with the proper inspect parameters. Note that you'll need at least version 6 or newer of Node.js for these parameters.

For example, if you want to debug your after_prepare hook, you invoke the cordova prepare ios command like this:

$ node --inspect --inspect-brk ./node_modules/.bin/cordova prepare ios

Debugger listening on 127.0.0.1:9229.  
To start debugging, open the following URL in Chrome:  
    chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/dc9010dd-f8b8-4ac5-a510-c1a114ec7d29

Navigate to the URL given, and it should be paused courtesy of the --inspect-brk parameter. At this point you should be able to locate your script in the sources panel, set breakpoints, and then resume execution once you are ready. Once Cordova reaches the build hook phase, your breakpoint should hit!

If you are having trouble setting a breakpoint, you can also place a debugger; statement as the first line of your exported function.