OMSK Pong is a Nintendo 64 Homebrew game developed by Omsk and published 04 June 1999 on The game, as you might expect, is a Pong clone. It’s a great place to start when developing games for a particular system. There are a few things that make OMSK Pong interesting:

  • The source code has been made public.
    • Images are saved and convered as ppm files
    • There is a .map file. There were no such files in any of the demos included in the SDK.
  • There is a rather long readme with some details about the development process.
  • Was compiled using PI.
    • This means that the Makefile and Spec file are completely different or absent. The C code is similar to normal N64 C code though.

You can find the source code and the .v64 ROM file for the game here.


The game is about as basic as it gets. It’s a Pong game that allows fora 2-player mode or a one-player mode versus an AI. The game features several images of aeroplanes for the menu screen and each of the result screens, plus a faded background of anime girls for the actual gameplay. The winner is the best of six. The game contains no sound effects or music.

As a game it works alright. The worst part is that when a point is scored, the pallets snap back to the middle (which is disorienting) and the ball/puck starts moving right away. This makes it very easy to miss a shot right after scoring one.


Readme transcript
omsk presents———————————————-
—————————-Pong + Source code – 04-JUNE-99
[email protected]———————————————-

The code of this demo is surely very shitty cause I only code in c for 3 months… And i dont know any other prog language (i used to know basic when i was 10 but that’s all).

I know a pong game is shit. I know this one is more shitty than others, but as a newbie i am very proud to have made my first n64 game/demo !

Greetings goes to all sceners out there.

Big Thanx to Immo and Widget for the DNX Files whitout which i would never have coded on my beloved N64. Thanx to Widget for PPM2C which i used to convert all my bitmaps (count0: thetool alpha bit support does not work on my box, dont know why). You’ll notice that all hardware related code is taken from DNX files (mainly DNX08 and DNX15 I think).

Particular Greetz goes to ACTRAiSER for bringing us DEXTROSE, without which i would certainly not have bought my n64 + doc64. DEXTROSE is THE only TRUE N64 site all over the net.

Thanx to RedBox, Frac, Collin Philips,… (i don’t remember everyone since I am not that often ob the net) and others who helped me with technical questions on irc or on dex’ forum.

rules, dex rules, n64 scene rules !
MESSAGE TO THE WANNABEES: I made a shitty programe for my n64 even if 3 months ago I did not even know what c was. So I bought a C book. I read some of it. I downloaded every sources from dextrose and I read it. I compiled some of it. I tried to modify some other parts… and then it crashed. So i modified again and again and it worked. All I want to say is if I did it mainly by myself using the ressources available on the web, you can also do it alone. If you can’t I understand that senior coders don’t want to be bothered with lame ass questions whose answers are available on the net then fuck off. So if you want to code stop reading this fucking NFO file and start reading at some source code (I don’t recommend mine since it must be shitty coding because of my little experience..)

coding is more exiting than playing————————

Looking through the readme file is quite inspiring if you ask me. It doesn’t go into much detail as to what went into developing the game, but we can tell a few things about OMSK Pong from it.

The game was developed using code snippets from Dextrose and a good old fashioned C programming book with some elbow grease. A Doctor V64 was then used to load the ROM onto the console. Omsk converted the image files (ppm format) using the PPM2C program by a user called Widget. I suppose that it does something similar to what my X2C program does.

Besides that, there isn’t much to the OMSK Pong Readme apart from the special thanks to all the people that helped with the code. And let’s not forget my favourite quote:

So if you want to code stop reading this fucking NFO file and start reading at some source code


This code is quite useful to analyse since it has all the basics of making a game, except for the sound, of course. Oddly enough, it follows a similar structure to that of other demos I’ve  looked at such as nu0. It has a main process, it has a definition for the z-buffer and frame buffer, it has display lists and all that fun stuff.

Since there is no spec file included in the demo, I guess it’s safe to assume that the boot function is located in BOOT.C. The purpose of this file is to initialise the operating system and start an initial thread which launches the mainproc function. Nothing really out of the ordinary, but good to have it as reference for some useful function in the setting up of threads.

The bulk of the game code though resides in the MAIN.C file. Within this file, there are two important functions: mainproc and DemoLoop. Let’s have take a look at mainproc first:

void mainproc(void * arg) {
        /* DMA static segment to ram */
        osPiStartDma( & dmaIOMessageBuf, OS_MESG_PRI_NORMAL, OS_READ,
                (u32) _staticSegmentRomStart, staticSegment,
                (u32) _staticSegmentRomEnd - (u32) _staticSegmentRomStart, & dmaMessageQ);

        /* Wait for DMA complete */
        (void) osRecvMesg( & dmaMessageQ, NULL, OS_MESG_BLOCK);

        /* Start rocking */

It’s pretty straightforward – it takes the segment (which would usually be defined in the spec file) and loads it into the RDRAM. Then it waits for it to complete and then loads the DemoLoop function which is the actual gameplay for OMSK Pong.

I won’t get into too much detail regarding the rest of the code in DemoLoop, but I will mention some odd ways in which it’s coded. However, there is something that I find a bit odd. It might be the case with other dextrose-era homebrew games, but display lists are run completely differently. Rather than creating a display list and then executing it, the DL is bookended like so:

guSprite2DInit( & MySprite[6], title, 0, 320, 320, 240, G_IM_FMT_RGBA, G_IM_SIZ_16b, 1024, 1024, flipx, flipy, 0, 0, 0, 0);
gSPSprite2D(glistp++, OS_K0_TO_PHYSICAL( & MySprite[6]));

A bit odd, but it works. Rather than having to constantly build display lists externally and then reference them, they are built straight into the code. I guess it makes the coding process a bit more stright forward. Have a look through the source, I’m sure you’ll find more interesting tidbits here and there.

OMSK Pong Gallery

Title menu.

Game screen.

Draw screen.

Player one wins screen.


Articles across the web

OMSK Pong is a Nintendo 64 Homebrew game developed by Omsk and published 04 June 1999 on "Coding is more exiting than playing". Let's have a look.
Article published on N64 Squid


Subscribe to the mailing list

Follow N64 Squid

  • RSS Feed
  • YouTube

Random featured posts

Leave a Reply

Your Name (required)

Your Email (required)


Your Message