Article: Making a SNES game in 2020

Making new games for retro consoles is something  that amateur developers can do quite easily thanks to today's  technology. Last year, I released a new game for my favorite console: the Super Nintendo (SNES). The project went as far as an actual physical release, with a cartridge and a cardboard box like the 90's. In this article,  I'll present you the numerous steps of this incredible journey: designing  the game, overcoming SNES-related technical issues while programming  it, manufacturing new SNES cartridges, and creating the manual and box.

The game : Yo-Yo Shuriken

Yo-Yo Shuriken is a fast-paced arcade game for 1 or 2 players on Super Nintendo (SNES).

The core gameplay revolves around shooting a single shuriken that you can magically recall at any time, so you can hit enemies from the front or from behind! You can even focus energy into the shuriken to deliver a powerful charged attack that can cut through several enemies at once.

Gameplay video: https://www.youtube.com/watch?v=rv4nUlAEt9w 

The game is available on cartridge with a beautiful cardboard box and a manual from Catskull Games:
https://catskullgames.com/yo-yo-shuriken

And if you prefer to play it on emulators, you can also get the ROM of the game here:
https://drludos.itch.io/yo-yo-shuriken

Now that you are more familiar with the game itself, let's explore how it was designed.

Designing the game

Making Yo-Yo Shuriken was quite an organic process. I tested gameplay ideas as I came up with them,  and tried to refine them until I had a "fun" game in hand. Let's start  with the initial idea. For a long time, I wanted to make a shooting game with a single bullet. So the player must retrieve it each time he shoots. Besides the "one bullet" idea, I also wanted to make a game that could be enjoyed with a friend,  in co-op. With both ideas in mind, I created the game step-by-step.  Each major progress I made was labelled as a new "version" and  playtested heavily. If the current version was good, I continued to add  new features. Else, I kept working on the current features until the  game was fun to play again before adding anything new. Here is a rundown of the major game prototypes, with screenshots. If you want to play the actual ROMs of these prototypes, they are one of the many perks available to my Patreon supporters.

1) Cyber Ninja - version 1

The first thing to do when making a game on a platform you don't know is to display something onscreen!  So I drew a robotic ninja sprite and tried to have the SNES to display  it onscreen. When it worked, I added code to make the sprite moves with  the D-Pad. And then  I made a walking animation when the sprite moved.  These firsts steps may look simple. But remember that it was my first time making a game for the SNES!  So it actually took quite some time to do, as I was learning how the  machine worked while making the game. As the current project only  displayed a robotic ninja, I named it "Cyber Ninja."

2) Cyber Ninja - version 2

The actual player sprite, a ninja, appeared in  this second version. So the robot sprites naturally became their  enemies, as everyone know that ninja and robots hate each other! As a  proud ninja, the player can throw a single shuriken. The shuriken can  get stuck on the screen border, and the player must pick it up to be  able to shoot again. The robot enemies can move aimlessly on screen, but  no collision detection is performed yet.

3) Yo-Yo Shuriken - version 1

After several tests, I thought that the shuriken could come back to the ninja automatically when the player pressed the button a second time.  I had a lot of fun while testing this mechanic, so it became the core  of the whole game! I also changed the project title to reflect this  evolution: say goodbye to "Cyber Ninja", and welcome to "Yo-Yo Shuriken"! Indeed, in the game the shuriken goes back-and-forth, much like a yo-yo.

I also added collisions detection. Now the  robots disappear when the shuriken hits them. But if a robot hits the  player, he's the one who disappear. While everything is still in a very  basic state, the core gameplay of the game is almost complete in this third game prototype. So I decided to "stress test" the engine to see how far I could push it before the game lags. I managed to have up to 80 enemies  walking and interacting on screen. Remember that a SNES can display a  grand total of 128 sprites, so having 80 of them updated 60 times per  second with collisions and animations is some kind of achievement.

4) Yo-Yo Shuriken - version 2

In this fourth version, the enemies are no  longer limited to straight line movements. They can now move in several  directions. They also bounce off the screen borders to avoid exiting the  game area. The game became more interesting as a result.

5) Yo-Yo Shuriken - version 3

I added a different background color, and a  system to spawn enemies endlessly. In the previous version, once the 80  robots were destroyed, the game was empty. Here an endless army of robots is generated!  The enemies can also follow the player, to force him to keep moving.  Indeed, in this fifth version, the game became  quickly boring if the  player remained static.

6) Yo-Yo Shuriken - version 4

In this version, I faced my first big technical difficulty: displaying large explosion sprites whenever a robot dies. I chose to have quite small player and enemies sprites : 16x16 pixels. That way, I could display loads of them on screen while keeping enough empty space for the player to move around and avoid hitting enemies (the SNES screen resolution is 256x224 pixels). However, I decided to draw my explosions at larger size: 32x32 pixels. The Super Nintendo is capable of displaying two different sprites size at the same time. The developer can choose a "small" and a "large" sprite size from a short list of sizes (8x8, 16x16, 32x32 and 64x64)  and the console will use this information when accessing the video ram  to display the sprite data onscreen. This is one of the many graphical  features that make game developers' life easier. But as any technical  feature, it can become daunting when you don't know how to use it!

In my case, in this current prototype, I was  only able to display a small portion of the explosion sprites, no matter  what I did. The issue was actually quite simple: I wasn't uploading the sprite data where needed in the SNES video memory. So the machine couldn't read them back. I did find the solution after spending several hours on the wonderful documentations made by the homebrew community over the years. I thank them a lot for their hard work on creating and sharing all this precious knowledge: without them, amateurs like me wouldn't be able to make SNES games!

7) Yo-Yo Shuriken - version 5

This prototype marks the addition of another key feature: the two players co-op mode!

New kinds of enemies join the fray too: the orange robots can take several hits before exploding, and the blue robots can chase the player anywhere. I also added coins that you have to collect to score points. This mecanic greatly improves the gameplay. Indeed, the only way to score points is to collect coins.  Killing robots doesn't bring you any "reward" per se, it's just a way  to prevent your avatar from dying. The robots drop coins when they die.  But the coins disappear after a few seconds. And there are always loads  of robots on screen, that will kill you instantly when touched. To earn points, player must thus take a lot of risks and move among the robots, else he won't be able to make a high score. But sometimes, it's better to let some coins disappear to avoid losing a life. This is what game designers call a "risk / reward" choice, and it's a great way to make a game interesting. Here, this mecanic allows Yo-Yo Shuriken to offer a smooth difficulty progression to  players. Usually, a rookie player will tend to stay static, and will  solely focus on destroying the robots. He won't get points, but he will  be able to continue through the game and defeat the final boss. Once a  player starts to get more confident, he'll be able to collect coins to  make a highscore. And of course, experienced players can try to make a  "perfect run" by collecting all the coins, although it means taking an  insane amount of risks!

8) Yo-Yo Shuriken - version 6

As playtesting went on, I realized that the game  was becoming quite repetitive. I tested several ideas to solve this  issue. The one I found the most interesting was to hold down the shoot  button to "charge" your shuriken. When you release the button, it  triggers a "super shot" that can cut through several enemies.  This mecanic brings a bit of strategic thinking to the game. Now, the  player can choose to perform several simple shots to kill the enemies  one by one. Or he can choose to perform a charged shot to kill several  enemies at once. But then he'll be vulnerable while the super shot is  charging.

9) Yo-Yo Shuriken - version 7

Starting with this version, all the game  mecanics that defines the core gameplay were in. So the project entered  the longest and most tedious phase: adding content and polishing the game. First, I added sound effects, that I created with BFXR. I also included the wonderful music tracks composed by XRACECAR. I also modified the game GUI and moved it to the top of the screen.

Regarding graphics, I added a pattern to the game background.  As my artistic skills are limited, I had an hard time drawing a  convincing background. I made several attempts, including this one,  before settling on a "wood planks floor" to emphasize that the game  takes place inside a dojo (see next version).

Last but not least, I started to create the various game levels.  Each level is composed by several enemies waves, with increasing  strength and numbers. I spent an insane amount of time testing and  balancing those enemies waves to make the game entertaining. Each game  designer does this his own way. Personally, for an arcade game, I like  to mix intense and challenging moments with easier moments  so the player can catch his breath. For example if the player manage to  pass a moment with fast moving robots chasing him while the dojo is  already filled with slow moving enemies, I'll reward him with a  slower-paced moment. Like 4-5 basic enemies moving very slowly so you  can easily kill them and collect their coins.

On a side note, you may notice that the explosions graphics are still particularly hideous at this stage.

10) Yo-Yo Shuriken - version 8

In this version, a new type of enemy joined the fray: the "shield" robot.  They can only be hit from behind. The "yo-yo shuriken" mecanic becomes  even more meaningful here. Indeed, the best way to kill shield robots is  to shoot around them first. Then, you'll have to call the shuriken back  and to try to hit them by controlling its return trajectory. I also  made new explosions sprites, and the background image is better looking.  I even added an invincibility bonus pickup (a white ninja head, replaced by a star in the final game).

11) Yo-Yo Shuriken - version 9

The last major feature arrived in this version: the game bosses. I spend a lot time designing and testing numerous bosses. This was one of the most enjoyable part of the game development process!

In the screenshots, you can see a prototype of the "snake" boss, and a boss not present in the final version: the tank. The tank boss must be destroyed in several steps. It has several weak points (the orange balls)  that have to be hit one after the other. Once a weak point is  destroyed, it removes part of the tanks structure, exposing new weak  points. This was a challenging boss. For example, one weak point is at  the end of a tunnel, so it requires a very precise aiming.

On paper, this boss idea was quite interesting.  It took me quite several days to program it. But after many play  sessions, I decided to removed it from the game as it was boring.  Indeed, it was sometimes quite hard to destroy the boss because of its  huge size. Also, if the boss managed to block you into a corner, you  were dead as you couldn't hit any of its weak points. In the end, facing  this boss was a more frustrating than fun experience. As you can see,  even in amateur game projects, sometimes you have to cut disappointing content despite the time you spent making it! 

12) Yo-Yo Shuriken - version 10

The key word of this final version was "polish."  I added the title screen, the introduction and ending animations, and a  screen to explain how the game plays. The final touch was to include a hidden bonus mode:  the "double ninja" mode, where you can control two ninjas with a single  controller. To unlock this mode, you simply need to finish the game  once (or use a cheat code!).

So, after more that one year of development and 5491 lines of code, Yo-Yo Shuriken was finally completed! The game ROM works perfectly. It was tested on several versions of the original game console (Japanese Super Famicom, US Super NES, PAL Super Nintendo); on modern versions (PAL modded with the 50/60hz kit from FFVIMan, Analogue Super NT); and on many emulators (Higan/BSNES, SNES9X, ZSNES, No$SNS, RetroArch, etc.) for various platforms (PC, smartphone, PSP, Raspberry Pi, etc.).

Once the game software final version was validated (all bugs fixed after an extensive beta testing phase), the hardware part of the project could begin.  In other word, we needed to make the game available on actual  cartridges with a beautiful cardboard box! But before exploring that  part of the process, I'd like to give you more details on developing this game for a SNES.

Programming the game

Making games on retro platforms comes with a lot of technical constraints.  Using modern tools does simplify the task compared to what the  developers from the 90's faced. But you still have many constraints  related to the limited specifications of the hardware. Like all the  other homebrew developers, I struggled with these limitations while  making Yo-Yo Shuriken. Here are the tools I used and the main issues I faced. I hope they'll help you figure how the SNES works under the hood.

Tools of the trade

Back in the 90's, game programmers had to learn and use assembly for each machine they were working on. The SNES was a difficult machine to work on  because you had to learn not one, but two assembly languages: The 65816  assembly for the CPU, and the SPC700 assembly for the audio chip.

Nowadays, you can still use assembly, and it's  actually the only route to get the most power from any retro machine.  But you can also make some really cool games with easier to learn  languages, like C or Basic. For the SNES, you have only one C compiler available:  tcc816. It's far from perfect, as you have to use some python script to  optimize / fix bugs in the code it outputs, but it works. A talented  coder named Alekmaul took this compiler and built a full framework to  ease the creation of games: the PVSNESlib.

I used this library to make Yo-Yo Shuriken, so I  could code it in C language. For graphics, I drew BMP images that were  converted to the SNES graphics format. For audio the framework accepted  wav files for sound effects and .it files (Impulse Tacker format) for music. It was still quite a challenge to make a game running on the SNES, but PVSNESlib made it a "hard but fun challenge"!

How does a SNES works anyway?

Compared to other machines like the Mega Drive / Genesis or the PC-Engine / TurboGrafx16, the SNES is quite a complex machine, with a lot of different graphics modes. But it's general workflow is actually quite simple. Basically, a SNES can display graphics data using two channels: the "background" and the "sprites". The background is a full screen image made of 8x8 tiles. The background can have several layers (from 1 to 4)  that can be scrolled independently. The video RAM is limited, so you  usually have to stream graphic data from the cartridge ROM to the video  RAM in real time in order to display some endless or large scrolling  areas.

For the sprites, the SNES can display different sizes: 8x8, 16x16, 32x32 and 64x64 - only two of such sizes can be on screen at the same time.  To animate sprites you have to manually set their position on screen  and modify the graphical data that they will display, 60 times per  second. To do that, like with the background, you first have to copy the  graphical data (i.e. part of your spritesheet) from the cartridge ROM chip to the video RAM of the console.

The SNES can also play audio using a dedicated  chip (SPC700). For input, it's quite easy to read what buttons players  pressed on the SNES gamepads. (the best gamepad ever designed!)

In the end, even if you use a tool like PVSNESLib, you'll need to be familiar with how the SNES works  in order to make actual games for it. Hopefully the wonderful homebrew  community have consolidated some very extensive documentation. I'll  recommend:

• The PVSNESLib wiki, that will guide you on how to set up the tools and how to make simple SNES programs: https://github.com/alekmaul/pvsneslib/wiki
• The NoCash SNES specs (technical, but thorough) https://problemkaputt.de/fullsnes.htm
• The SNESdev section of the NESdev forum: https://forums.nesdev.com/viewforum.php?f=12
  The community is very helpful and skilled. They saved my life more than once when I was making Yo-Yo Shuriken!

Now that we have covered some basics, let's dig into some technical issues I faced.

How many enemies can we display on screen?

In a game like Yo-Yo Shuriken, the more sprites on screen (enemies, explosions, etc.), the better the game will be! However, the game cannot afford to lag. So you have to find the maximum number of enemies that the CPU can handle while keeping a smooth 60 fps display. The SNES is often touted as "slow" compared to the Genesis / Mega Drive ("Blast Processing" anyone?).  And, in a way, this is true. While the SNES can display more colorful  images and higher quality sound, the CPU time available is usually lower  than the Genesis. In other words, the Genesis could usually moves more  sprites on screen that the SNES. The best example of this difference are  Contra III (SNES) and IV (Genesis). And more specifically, how each  game handle explosions:

Explosion on SNES' Contra III (left) are made with a few sprites alongside a special graphical effect (transparency), while Genesis' Contra IV (right) renders them with an insane amount of sprites  on screen. When programming each console like they are meant to be,  directly in assembler, you can feel this difference in processing power.  But when using a C compiler like I did for Yo-Yo Shuriken, the  difference becomes even more obvious. So the total number of enemies I could display was limited by the CPU time available.  But the CPU tasks are not limited to sprites management. It must also  handle animations, upload graphical data to the video ram, manage  collisions, read controller inputs, trigger sounds and music on the  audio chip, etc. Developing Yo-Yo Shuriken was a constant struggle to keep as many enemies as possible onscreen,  while all the other elements were eating the total CPU time available.  Hence, I had to decrease the number of enemies several times as I added  new features to the game.

At first, when there was only standard robots moving in straight line without collision detection, I was able to display 80 enemies onscreen (plus 1 player and his shuriken). When I added collisions detection between enemies, player and shuriken, I had to reduce this number to 40 enemies.  Adding the second player, explosions, sound effects and music also took  a big chunk of the CPU time available. In the end, the final game can  only display up to 24 enemies onscreen in order to  maintain a smooth 60 fps display rate. While it may sound little on  paper, when you'll play the game you'll see that 24 enemies are more  than enough to offer a though challenge, especially in the later levels  of the game!

Honestly, being able to manage 38 animated sprites on screen (24 enemies + 2 players + 2 shurikens + 10 explosions) without any slowdown is still an achievement. But there is a trick behind this achievement: not all the sprites are updated every frame. Indeed, while the player and shuriken are updated 60 times per second, the enemies and explosions are updated only every two frames,  and even every fourth frame in some cases. This programming trick was  quite common during the 90's. It allows spreading the collision-related  computations over several frames in order to display more sprites on  screen without slowing down the game frame rate.

LUT makes sprites go round!

While the standard enemies have simple movement  patterns, with straight or diagonal movement, the bosses move in more  complex fashion. For example, many bosses have balls spinning around them.

From a mathematical standpoint, you simply need to compute the sine and cosine of each ball angle to move them in a circular motion. On a modern platform, such computations are easy and fast to do. But on retro platforms, this is quite a challenge! The 8/16 bits machines CPU don't have inner functions  to compute sine and cosine in hardware. So you have to compute them in  software by combining a lot of more complex calculations. This obviously  takes a significant amount of time. The SNES wouldn't be able to compute  the sine and cosine for 24 enemies at a 60 fps rate in addition to  everything else. As the balls move slowly, they are actually updated  only once every 4 frames, bringing the number of calculations from 24 to 6. But in this particular case, this is still too much: the CPU can't compute 6 sine and 6 cosine every frame in addition to all the other tasks.

Of course, there is a trick to solve this particular issue, one that was also very common in the 90's. To reduce the load on the CPU, you can simply use a "Look-Up Table" instead of doing the sine and cosine calculations every frame. Simply put, I calculated the values of sine and cosine for a large range of angles in advance, using a spreadsheet program on my modern machine. Then, I stored all these values in a giant table inside the game ROM.  That way, the CPU can now read the values of sine and cosine it needs  to move the balls in the ROM, instead of wasting time to compute them  every frame. This giant table of precomputed data is called a "Look-Up Table",  or LUT. LUTs were very common in games made before the 32 bits era. And  they are not limited to sine and cosine! Anything that is "slow to  compute" on a CPU will usually be computed in advance so the results can  be stored in a LUT: trigonometry, color effects, random number generation, raster scan effects, etc.

When the 32 bits consoles arrived, this issue  was solved because their CPU featured hardware function to perform  trigonometry calculations in a flash. Indeed, trigonometry is an  essential part of any 3D based rendering. So machines like the  PlayStation and the Saturn needed to be able to do it quickly and  repeatedly every frame. When reading this, you might be wondering: if  this is true, how can the SNES render 3D graphics in a game like Starfox?

In this case, a LUT wouldn't be enough: there are too many calculations to do. So the creators of Starfox simply added a new processor that can compute trigonometry quickly inside the cartridge: the famous "Super FX" chip!  The SNES wouldn't be able to compute and display of all these 3D  objects without the Super FX. But Starfox isn't the only game to use  such a chip. Super Mario Kart and Pilotwings use another chip  for the same purpose, the "DSP-1". Like the Super FX, it can perform  trigonometry calculations faster than the SNES CPU. While the DPS-1 is  only used to do calculations, the Super FX is much more powerful and can  actually render polygons onto a 2D framebuffer, like the PlayStation  and the Saturn do.

Watch out for VBLANK!

Once the CPU has finished to compute, it must  tell the graphic chip to display the result of its computation on  screen. This how any console work, whatever its release date. But the  ones from the 8/16 bits era have a specific behaviour: the CPU can only send data to the graphic chip during a specific time period: the "VBLANK." But what is the VBLANK?

On a standard CRT television, the image is drawn though an electron beam that moves from top to bottom and from left to right.  While the electron beam moves behind the screen to draw the image, it  paints "pixels" of a specific color by using instructions from the  console graphic chip. Without this graphic chip, the electron beam  wouldn't know what color to paint, and thus no image would show  onscreen. Once the electron beam has finished to paint an image, it  reaches the bottom of the screen. It must then go back to the top of the  screen to start painting a new image, using the new instructions sent  by the graphic chip. The time period while the  electron beam is off so it can moves back to the top of the screen is  called the "Vertical Blanking", or VBLANK.

On a SNES, when the graphic chip sends instructions to the electron beam, it cannot do anything else.  Moreover, you can't even modify the video memory at this time, as it  contains the image to display on screen. Indeed, the graphic chip needs  it to control the electron beam. If we somehow manage to modify the  video memory while the graphic chip is displaying a image on screen, it  would display a corrupt image, or worse. So the SNES is designed to  prevent this: the CPU simply cannot access the video memory while the graphic chip is displaying an image.  The CPU needs to wait for the VBLANK period to be able to send the  graphical data of the new image to display onscreen in the video memory.  And this period of time is quite short.

So, what are the actual consequences of all these VBLANK related limitations? Simply put, it's another harsh limitation on the total time available for game developer to display their game onscreen. First of all, to prevent the game from lagging, you need to perform all the gameplay calculations (collisions, movement, animations, etc.) between two VBLANK periods.  If the game code takes more time to compute, you won't be able to  display the resulting frame on time, and thus the game will visibly be  lagging onscreen.

But an even harder limitation is that you can only send very few graphical data to the video memory during every VBLANK.  Indeed, the graphical data transfer speed is limited by what is called a  "bus". The "bus" is the actual electronic line connecting all the chips  together. If you try to send more data than what is possible to  transfer during the VBLANK period, the additional data will simply be  cut off and not displayed.

A vicious bug: the 50hz/60hz trap!

I experienced the VBLANK limitations first-hand while making Yo-Yo Shuriken. It was the cause of the one the most vicious bug I encountered during the whole project. During beta tests, using the ZSNES emulator and my own console, everything was displaying fine. But, when I tested the game on other emulators that are known to be more accurate than ZSNES, namely SNES9X and Higan/BSNES, some sprites weren't displayed. More specifically, the explosions were "cut" as you can see in the images below:

ZSNES and my console (left) / BSNES-Higan (right)

For weeks, I tried to solve this issue, without success. I was finally able to fix it thanks to the help of wizards from the SNESDev forum.  the SNESDev community helped me more than once during this project, and  I couldn't be more grateful for all the help they provided! They found  that the cause of this issue was simply that I was sending too much data to the graphic chip every frame.  The time needed to transfer all the data was exceeding the VBLANK  period. So the explosions animation didn't have the time to reach the  graphic chip before the end of VBLANK, and was simply cut off. But you  may wonder: why was this bug only happening on some accurate emulator, and not on the real console?

This is where the bug becomes vicious. As all SNES lovers living in Europe, my childhood console works in "PAL" TV format, running in 50hz. In other words, the graphic chip of the console displays a new image onscreen 50 times per second. In the US and in Japan, the TV format is different: it's "NTSC", running in 60hz. Thus the NTSC consoles display a new image on screen 60 times per second. Does it means that American and Japanese games run faster than European ones? Sadly, yes! (but we didn't knew it during the 90's...). Ask any fighting game fan, and they'll explain you why the NTSC versions are better to play: faster, smoother, no black border, etc.

Nevertheless, the PAL format does have one advantage over the NTSC one. As PAL TVs displays 50 images per second instead of 60, the electron beam moves slower. Therefore, the VBLANK period is longer on PAL consoles  than on NTSC ones. So you can transfer more graphical data every frame  on a PAL console compared to a NTSC model. And this was the root cause of my bug.  When I tested the game on my childhood console, running in 50hz, the  explosions sprites were perfectly displayed because the VBLANK period  was long enough for all the data to transfer correctly. But on  BSNES/Higan, an extremely accurate emulator running in 60hz, the sprites  were cut off as the VBLANK is shorter, and all the data couldn't  transfer in time. But why does ZSNES, also running in 60hz, did display the sprites without issue?

Well, simply because ZSNES is an older emulator, with less accuracy  when it comes to reproducing all the technical limitations of the SNES.  For instance, ZSNES doesn't prevent you to modify the content of the  video memory outside of VBLANK - a major technical difference compared  to the real console! In the end, this issue proved me how important it  was to use accurate emulators when developing homebrews, and that nothing can replace testing on actual hardware,  and on all the hardware versions. So I did have to buy an extra SNES  running in "60hz" to be able to test the game more thoroughly!

Going physical: making cartridges

To me, an homebrew project isn't completed until players are able to put an actual cartridge of the game in their own childhood console.  But how can we create a physical release for a console that the sole  cartridge manufacturer, Nintendo, have ceased production about 20 years  ago?

The answer is simple: you have to manufacture them yourself! For this part, I partnered with an electronics wizard named Catskull, who already designed cartridges for my Game Boy games. For this project, Catskull designed a new SNES PCB from scratch. He used new components only, namely Flash ROM. All the cartridges are built by hand. Here is a detail of the full assembly process with pictures:

1) Bare PCB

Let's start with the beginning: the bare PCB.  Catskull have the PCBs professionally manufactured. He receives them  "naked", as shown in the picture below:

2) Applying solder paste

To add components (i.e. electronic chips) to the PCB, you first need to apply the solder paste. It's a "glue" that will tie the chips onto the PCB. This is a meticulous task. Catskull uses a mask to apply the paste to the required areas only:

As a result, the PCB now have paste on all the part that will host components:

3) Laying down components

This is another meticulous task. All the components (chips) must be placed on the PCB. Catskull builds 5 PCBs at a time (you'll see why in the next step). Here are the PCBs without components:

And the same PCBs with all the chips laid down where they belong:

4) Baking cartridges!

The solder paste is like a cement for  electronics chips. When applied, it's still "wet", so you can reposition  the chips if needed. To finalize the PCBs, you need to dry the paste with an oven. So technically, the last step of the build process is to "bake" the cartridges:

5) Flashing the game ROM

Now that the electronic circuit is ready and working, we can write the game ROM onto the memory chip. To do this, Catskull uses the wonderful INLretro Dumper-Programmer by Infinite NES Lives. For those who don't know him, Infinite NES Life is another electronics wizard who created many hardware components for NES and SNES.  He published several high profile NES homebrew, he's sponsoring the  annual NESDev competition, and he sells NES and SNES PCBs and carts for  people who want to produce homebrew: http://www.infiniteneslives.com
 

Both Catskull and I would like to thanks a lot Infinite NES Lives for his support on this project.  First of all, he helped Catskull to fix the PCB pinout. Then, he added  support for Catskull PCB on his flasher, so we could use it to  manufacture our game. And, last but not least, he supplied us with the  CIC chip that is required to build cartridges that can boot on original  consoles! So thanks to INL, Catskull can now easily transform his  hand-assembled PCB into a working SNES game cartridge running Yo-Yo  Shuriken:

6) Housing the PCB into the shell

To complete the cartridge assembly, Catskull puts the PCB inside a cartridge shell. As you may know, the SNES commercial releases from the 90's had two cartridge shells variants.  The Japanese and European ones had rounded edges, while the US ones  were a bit larger and more rectangular. Of course, you can't plug a  Japanese/European cartridge in a US console, and vice-versa.

For Yo-Yo Shuriken, we wanted to make a single worldwide version. So we had to use a shell that could be plugged into both consoles variants.  Luckily, there are people who designed "universal shells" that can be  plugged into all consoles models. For example, you can easily find such  shells in China for a low price. But we wanted higher quality materials. Hopefully, Catskull managed to find an US-based supplier who designed his own universal SNES shells,  made with a high quality plastic. These shells obviously cost more, but  when you have them in hand they offer a nice "sturdy" feel, like the  original cartridges. This justified the extra cost in our eyes.  Moreover, those high quality shells also bring a unique touch  to the Yo-Yo Shuriken release: they are only available in red color.  While I was surprised at first, I now find it very cool as it's a nod  the bright red eyes of the numerous robots enemies in the game! Here are  pictures of these shells (front / back):

Of course, the cartridge shell also needs a label with the game name  applied on it, but we'll see that step in the next section. To end this  rundown of the PCB assembly process, here is an issue that Catskull  faced when making the first unit: 

"The one thing is that SNES PCBs have their  components on the rear side (facing away from you when it's in the  console). So in all those pictures, I'm working on the rear of the PCB.  The first one I accidentally plugged in backwards in the console because  I didn't have it in a shell, and it fried the components on the PCB!"

Going physical : making boxes and manual

Having a PCB is only the first step  towards a full cartridge release. These PCBs needs to be housed in  shells, with a neat label, and packaged into a beautiful cardboard box  with manual. While Catskull was busy designing and hand-assembling the  cartridges, I designed the cartridge label, manual and cardboard box myself.

Cover art

I'm far form being an artist. But one of the pleasure of amateur / homebrew project is doing as many things as possible yourself!  So I fully embraced the "amateurish" side of this project, and I  decided to draw the covert art myself! I started by doodling on paper:

Then I scanned this doodle and I redraw it on the computer using a vector drawing program:

Once the covert art was done, I used it to design the cardboard box, the manual and the cartridge label. The final version of all these elements are professionally printed in the US. But during the design phase, I had to print the prototypes with my own means!

Manual

For the manual, I used commercial games releases from the 90's as reference,  in order to produce something as authentic as possible. But we made  some compromise as wanted to produce a single version for all the  countries (no US/Japan/Europe variants like the old days). The end result is a mix of US and European design  style from the 90's. For example, most US release had black boxes and  manuals, while the European ones used a colored background. Here are  sample pages from the manual:

Box

For the cardboard box, I also used a mix of European and US design,  with the same color as the manual. I had to print prototypes with own  means to be sure that the size was right. For the manual, I could easily  print it on my own printer. But for the box, it used an A3 paper size. I  also had to print the box on cardboard to be able to build it. So I went to a local print shop in my neighborhood to print the box on a A3 cardboard sheet. Then I went back home to build it. I had to make several versions before getting the exact size of an original SNES game from the 90's, but I finally made it. Here is a picture of the last box prototype:

Once the box prototype was completed and validated by both Catskull and I, we found a supplier in the US that could build them using professional materials. We were very happy to found a supplier that could print the boxes on a cardboard material close to the ones from the 90's. If you open a Yo-Yo Shuriken box, you'll see that the inside is gray/brown, like the 90's releases, and not white like most retail cardboard stock. Each box is actually printed and hand assembled in the US by our supplier (a two-man operation), who ships them already assembled to Catskull. Catskull then adds in the manual and the cartridge, to obtain the final physical release of Yo-Yo Shuriken that can you see here:

Closing words

In the end, with all these steps, making Yo-Yo Shuriken took almost 2 years of hard work! I hope you enjoyed reading this article. It was quite a journey for me, and I'm happy to share it online with the hope that it will inspire and motivate other developers to make new SNES games!

If you want to play Yo-Yo Shuriken on your own console, or simply support my work, you can buy the beautiful boxed cartridge release directly from Catskul Games:
https://catskullgames.com/yo-yo-shuriken

If you prefer to play it on emulators, you can buy the ROM version from here:
https://drludos.itch.io/yo-yo-shuriken

If you enjoy my work and can afford it, you can support me financially on Patreon.  My games usually end up being released as freeware online, while some  of them are also sold on actual cartridges. By supporting me on Patreon,  you'll also gain an unique access to the beta versions of my games, and even to the various prototypes I create (including cancelled projects):
https://www.patreon.com/drludos

If you simply want to be notified of my latest games and articles releases, you can sign-up to my newsletter (I only use it to announce games and articles releases, so except about one email every 1-2 months at maximum).