Tag: famicom

Nicole Express on Twin Famicom Compatibility with Guardic Gaiden

Nicole Express is so knowledgable. How many blog posts have you seen about an obscure hardware issue, itself with obscure hardware, and the Japanese version of one specific cult game? Which the writer tested herself with her own unit and cartridge? Then went in to investigate herself with a freaking multimeter? Whaaa?

Nicole’s two Twin Famicoms

I won’t keep you waiting for the link: here it is. And here is my grossly simplified summary, intended to inspire you to go to the original article, if you have the time, and get all the deets.

Guardic Gaiden, known in the US as The Guardian Legend, uses a weird trick to put its status bar at the bottom of the screen, instead of, as usually seen in an UNROM game, at the top. To create a fixed status window requires stopping whatever the processor is doing at a very precise time while the display is being drawn to the TV, and then changing some PPU registers to display the status.

Guardic Gaiden’s title screen

More complex and versatile mappers, like the MMC family, have the ability to trigger interrupts at specific screen lines, but Guardic Gaiden/Guardian Legend doesn’t use an MMC. It doesn’t even have a raster line counter, so the game simply doesn’t know where on screen the raster beam is drawing.

There are still lots of games on the system that have status windows, even with MMC chips. The PPU has a built-in feature called Sprite 0 Hit, where the chip can signal when Sprite 0 (of the system’s 64 sprites) is being drawn on top of non-transparent background data. So what older games commonly do is put Sprite 0 in an unobtrusive place at the bottom of the status window at the top of the screen. When the Sprite 0 Hit register indicates a collision, the code knows it’s time to set up the PPU to display the main portion of the game screen.

There is a really big problem with this setup, though. Sprite 0 Hit doesn’t trigger an interrupt. It doesn’t stop the code to let it switch the graphics. It’s not even proper to say it “sends a signal.” It’s up to the code to check if Sprite 0 Hit has been triggered. If it has, then it’s time to set the scroll register to the right place, and maybe switch to the proper background tileset, and do whatever else needs to happen, and the code can then be off to run essential game logic, the actual game part of the game.

If it hasn’t… then, the code has to check again, and immediately. And if it hasn’t triggered then, to do it again. It has to literally check as quickly as it can, because if it delays in its check, the game screen might not get set up at the right moment, which will be perceptible as the bar straying down one extra line that one frame. Not the end of the world, but it looks glitchy. And this code will be running every frame, so if it strays down once, it might do it again, which is a more perceptible glitchiness.

Sprite 0 is set to trigger its hit at the top of the screen, because the code won’t have to spin its wheels checking the hit over and over. It wastes time, but not that much. This is why UNROM games put their status lines, with the score, timer, health bar and life counters, at the top of the screen.

Well, The Guardian Legend is an UNROM game, and maybe because creators Compile wanted to show off, they decided they’d put the bar at the bottom of the screen. And yet, their game doesn’t waste most of each frame just in maintaining the status bar.

How? And what does that have to do with the Twin Famicom? For that I’m going to direct you to Nicole Express’ blog post. May you find it as fascinating as I did!

Nicole Express: Is the Twin Famicom Flawed? The Case of Guardic Gaiden

NESHacker’s Guide to the NES Hardware

More and more I find I should do a blog search to make sure that I haven’t posted something before, and my search for this video didn’t find it. It did find our link to the Copetti Site’s discussion of various console architectures, and a separate link specifically to their explication of the SNES’ construction, but not this particular video from NESHacker, so it’s fair game. Post! (zoop)

It’s only about nine minutes long so you can guess that it doesn’t go into deep detail. Essentially the NES is split into two parts, the CPU and its memory, and the PPU graphics chip and its own memory. A lot of classic consoles and microcomputers had to take special measures to support their display, which often ended up being the most complex part of the unit. Think about it: you have what amounts to a deluxe broadcast character generator right there in a box on your desk, shelf or floor, with lots of extra bells and whistles besides. (In fact, home computers were often used to generate current events channels for local cable companies, and an Amiga was essentially the basis for the old Prevue Guide channel.) It’s like a tiny special-purpose, single-receiver TV station just for your own use.

Graphics hardware is extremely timing sensitive. It has to generate the signal for your TV to display according to standardized picture generation requirements, so special requirements are often necessary. In the Commodore 64, for instance, the VIC-II graphics chip has the power to actually put the 6510 CPU to sleep, so it can have unrestricted access to the computer’s memory, without fear of bus conflicts, when it’s needed. This reduces the overall speed of the processor by a bit, and it’s why C64s turn off the screen when loading programs from cassette tape, in order to keep the CPU timing consistent relative to the data being streamed in off the tape.

The NES gets around this by giving the PPU RAM and address bus for its own exclusive use, and to put stuff in it the CPU has to use the PPU as an intermediary. And what’s more the NES exposes both the CPU and PPU’s address busses through the cartridge connector (which is why it’s got so many pins), allowing carts to supply dedicated ROM and RAM to both chips.

Even though it’s just a high-level overview, I found it a worthwhile use of those nine minutes, and you may very well enjoy it too.

NES Hardware Explained (from NESHacker, on Youtube, 9 minutes)

Youtube Series: Inside the Famicom

It’s only two episodes in, but this series from the Youtube channel What’s Ken Making is already really interesting, with episodes averaging at around 16 minutes each. The first part is titled “The Design of a Legend,” which doesn’t really grab me much, but the second is about the main processor, “The 6502 CPU,” which Ken admits near the start isn’t exactly accurate. The Famicom/NES’s processor isn’t precisely a MOS 6502; it’s a Ricoh 2A03 in NTSC territories, and a 2A07 in others. The 2A03 is licensed from MOS, but lacks the original’s Binary-Coded Decimal mode, and includes the Famicom/NES’s sound hardware on-die.

Episode 1 (15 minutes):

Episode 2 (17 minutes):

That removed BCD feature. Why? The video notes that the circuits are right there within the chip, but have been disabled by having five necessary traces severed. The video notes that the 6502’s BCD functionality was actually patented by MOS, and asks, was the feature disabled because of patent issues? Was Ricoh trying to avoid paying royalties?

Chrontendo 64

Dr. Sparkle is back with the 64th installment (Youtube, 55 minutes) of his quest to review every NES and Famicom game. He’s pretty far in! In about ten episodes, he figures he’ll reach the launch of the Super Famicom, which won’t be the end of his journey but will probably mean he’s in the home stretch.

In the meantime, ten games from 1990 are in this episode. They are:

Puss ‘n’ Boots: Pero’s Great Adventure – Technically a retread of a previously-covered Japanese game, this version has substantial differences so Dr. Sparkle decided to cover its U.S. version separately. A very easy game until the last stage where it jumps in difficulty, and then the final boss is absurdly hard. Dr. S expresses confusion why a game made to be so easy that it’s obviously intended for young children would become nearly impossible right at the last second. Personally, I suspect it was done because NES game publishers were terrified of the game rental market.

Wit’s: A Japan-only release, this is basically a de-luxe version of Snake, where your enemies have special abilities that you have to account for. Suprisingly, it’s an arcade port!

Captain Tsubasa Vol. II: Super Striker: A weird RPG take on Soccer, published by Tecmo and based on a manga and anime series. Instead of controlling a player or players completely in real time, the action pauses frequently and asks you what to do. The main screen is mostly animations down on the soccer field. It’s a unique take on soccer, but it’s not the only one: this is the second game to play like this on the Famicom. The Captain Tsubasa game series continues even today: the most recent releases, Dr. Sparkle tells us, are on PS4 and Nintendo Switch, although I don’t know if they take the menu-based RPG approach.

Jyuouki: This is simply a licensed Famicom port of Sega’s Altered Beast, and a pretty bad one at that.

Mahjong G-Men: Nichibutsu Mahjong III: Yet another Mahjong game, although with some interesting features, if you’re into Mahjong. That’s not Mahjong Solitaire, a.k.a. Shanghai, the Activision (and formerly PLATO) computer game where you remove tiles in matching pairs from a tableaux, but the Chinese Rummy-like game using tiles instead of cards. It also has a weird Tetris-like subgame involving Mahjong tiles.

The Pennant League: Home Run Nighter ’90: Yet another Famicom baseball game.

Dr. Mario: The classic Nintendo puzzle game! I always thought it was a bit inferior to Tetris, but then most games are, and that didn’t stop me from playing a ton of it long ago.

Pictionary: Based on the board game, and coming from infamous American NES publisher LJN. Dr. Sparkle is a bit harsh on developer Software Creations, but I think this effort looks pretty well-made to me. It’s not a classic, and it’s actually not really so much Pictionary as a kind of variation on the theme, where players play mini-games to reveal parts of a drawing and then try to guess what the drawing is of. It looks much like one of Rare’s many game show and board game adaptations and creations, and in fact if it weren’t for the Software Creations credit I’d have assumed that Rare made it.

Bigfoot: From Acclaim and developed by Beam Software. It’s fairly well polished for a Beam Software title, but has some weird ideas to it, including a weird control scheme for the events that involves tapping left and right on the control pad. I think the idea has a bit of merit, but that it was probably the wrong place to use it. A Bigfoot game would mostly be bought or given to kids, who would be the absolute last demographic you should expect to master a non-standard control scheme. I’m not one of those people who thinks making a game that goes about its play differently than most other games is always a terrible idea (see: most of what I’ve ever written about roguelikes), and I can kind of see why they did it, trying to make a race game that’s more than just holding to the right. It probably could have used a bit more iteration though.

Snake Rattle ‘n’ Roll: A game from Rare that they actually put a lot of effort into, and it shows. And some people really like it, it’s definitely got a cult following. Dr. S isn’t part of it, due to the difficulty of getting used to SRnR’s isometric style. I think what happened was, they had these routines laying around that they used in implementing NES Marble Madness, and decided to do another game that controlled in that kind of way. I think the game was poorly suited to a digital control pad; if it were controlled with an analog stick, or at least a digital control where diagonal movement is easier, I think it’s possible that some people who hate Snake Rattle ‘n’ Roll might be able to enjoy it better.

Anyway, here is the whole episode, start to finish:

More From Displaced Gamers on Dr. Jekyll and Mr Hyde

We presented Displaced Gamers’/Behind the Code’s video on the jankiness of kusoge disgrace Dr. Jekyll and Mr. Hyde back on Saturday. They did another video on that game, that delves into why the game’s frame rate is so inconsistent. In summary, its engine throttles its framerate in a terrible way, using long delay loops. It’s a pretty awful idea! It’s 19 1/2 minutes long. The video claims it’s even geekier than their first video on the game, but I think it’s actually slightly less technical, at least it doesn’t fill the screen with as much 6502 assembly code.

Another fact about J&H: the Japanese version had two full levels that were cut from the U.S. version, which replaced them with replays of other levels. It made a bad game even worse!

Now, because of Behind The Code, you know more about the Dr. Jekyll and Mr. Hyde game than many much better NES titles. Congratulations!

Behind the Code: Dr Jekyll and Mr. Hyde

For some reason there’s been a lot of Youtube videos lately that fit our eclectic purview, so here’s a code-heavy dive into infamous NES disasterpiece Dr. Jekyll and Mr. Hyde.

It’s 19 minutes long, and is even geekier than is usual for us, going into a disassembly of the game’s machine code in its quest to make the game marginally less awful.

As long as we’re on the topic, here’s Jeremy Parish’s NES Works episode on Dr. J & Hyde, which is also 19 minutes, and also covers the somewhat better (but not hugely so) game Amagon:

While we’re on the subject, did you know that Jekyll & Hyde has a secret ending? Both endings are shown here (4 minutes):

The “bad” ending is the normal one, and shorter, but is arguably a happier conclusion to the story. To get it, all you have to do is get to the end of Stage 6 with Jekyll. That’s all.

To get the other ending, get to Stage 6 with Jekyll, then turn into Hyde and get to the end of his version of the stage. Usually, if Hyde gets as far into his level as Jekyll has gotten into his, he’s struck by lightning and dies. But in this level he’ll be allowed to reach the end of his version of the level for some reason, where there’s a boss! Beat it, and when you return to Jekyll’s world the enemies will be gone, and he’ll be free to finish the level without harassment. However, ending events will be different….

Mega Man’s Score System

Looks like we’re on another Youtube binge, ayup ayup. This time it’s another hopeful video constructor asking us to consider the oddity of the score system in the original Mega Man (a.k.a. Rockman).

When you post as many Youtube videos as I do, it’s easy to form opinions about their style. That of “TheRetroDude,” as he styles himself, is interesting, it’s still hyper-edited in the way that so many Youtubers loathsomely adopt, but it’s not nearly as distracting as those. He keeps the volume down, as well as the number of swoopy objects tearing around the screen like a toddler newly introduced to Toblerone.

He has good points about how extraneous the game’s scoring system is too, although his misgivings could be laid against many other games. In Super Mario Bros, score is mostly a spacer before toppled turtles start giving extra lives. I think that score isn’t a bad addition to a game as long as it’s implemented thoughtfully, yet for too long it hasn’t been. Even in the NES days it was included to give players a short term goal to aim for, when they didn’t really need it.

What would a good scoring system look like, one that rewarded skill? Well–

  • Losing a life would reset score to that at the last passed checkpoint, eliminating point pressing from lives.
  • Extra lives at game end would be worth a bonus each.
  • Game timers are worth a small, yet substantial, award at level end, to prioritize fast play over slow.
  • Awards should be given for score, most typically extra lives, but others are possible too.
  • Replaying levels, and other means of “minting points,” earning arbitrary scores, should be ruthlessly eliminated. If the player can replay levels indefinitely then think about if your game really needs a score, and if it does, don’t allow players to earn more points from replaying them without costing them the points from that last pass.

Two games that come to mind that do scores well are:

  • ZANAC on the NES, being a scrolling shooter without checkpointing score is generally fair, although it is possible to warp backwards does break the no-replay rule, and
  • Star Fox 64, which only adds a level’s score to the player’s total at its end. SF64 is a game obviously designed around score attacks.

Where was I? Oh! Here is that video about Mega Man’s scoring system.

Mega Man 1’s Really Weird Score System (Youtube, 9 minutes)

The 10th-Key NES Pac-Man Scatter Bug

I already shown it off on Mastodon, but I’m so pleased with getting this bug on video that I’m re-reporting it here! First, though, some background.

Still the definitive resource on the design internals of Pac-Man.

I’ve been looking into the various home computer ports of Pac-Man lately. One of the better ones is the one for Famicom/NES, probably because it was made in-house at Namco, which I presume because while it’s by no means perfect, it has ghost AI that much more closely matches Jamey Pittman’s definitive Pac-Man Dossier than the others. This is a bit more important than the other ports because, due to the relative familiarity (that is to say, inexpensiveness) of NES emulation at this point, Famicom Pac-Man is often put in compilations, especially in dedicated consoles, instead of the arcade game. In point of fact, the Namco Museum Archives Vol. 1 that’s available for various consoles uses the Famicom versions of all its games, not the arcade, and Pac-Man is one of the included games. To tell the difference: if the score, fruit tally and lives are to the right of the screen, instead of above and beneath it, and Pac-Man looks a little too big to fit in a maze passage, then what you have is an inferior home conversion.

How is it different? Well:

  • The sound of Pac-Man eating dots is much worse, for starters, it never fails to bother me.
  • More substantively, the ghosts have slightly different constants in their chase routines: it’s slightly harder to fake out the Pink ghost (Speedy/Pinky), and the Orange ghost (Pokey/Clyde) gives up the chase a little more reluctantly.
  • The timing for scatter periods, relative the speeds of the ghosts, is a little off. Scatter periods are usually slightly longer.
  • The speed of the game as difficulty increases is also a little off. In the arcade, the First Apple board (Level 5) marks a noticable increase in Pac-Man’s speed, but it seems to happen around the Second Orange (Level 4) on Famicom. Yes, that’s how much of arcade Pac-Man and its port that I’ve played-it could be subjective, but maybe it’s not.
  • The bug that affects Pink’s and Blue’s (Bashful/Inky) AI when Pac-Man’s facing up doesn’t exist here.
  • When ghosts enter Scatter mode, they don’t reverse direction. This makes the game easier (one less sudden reverse to throw you off) and harder (no obvious indication that the ghosts are scattering, and one less thing to throw them off from immediate pursuit).
  • As the game advances in difficulty, in the arcade, on the 4th Key board (level 17), the ghosts won’t turn blue and vulnerable when you eat an Energizer, and instead will just reverse direction. And from the 6th Key (level 19) on, the ghosts will never turn blue again! NES Pac-Man instead gives them a very tiny bit of blue time, about a half-second’s worth. It never reaches a state where the ghosts become completely invulnerable.

And at last, the bug which I have confirmed. On the 10th Key board (Level 22), and every level thereafter, the ghosts will start out in an unusually long Scatter period. Their usual habit is to emerge from the box in the center of the screen and move to a corner of the screen, and circle there for a few seconds. Pink goes to the upper-left, Red (Shadow/Blinky) to the upper-right, Orange to the lower-left, and Blue to the lower-right. This period is called a “Scatter Mode” in the Pac-Man Dossier.

In most levels, presuming you don’t lose a life, the ghosts will enter Scatter Mode at exactly set three times: from the start, about 25-or-so seconds in, and about 30 or so seconds after that. These periods are usually five seconds long. There are some minor details I won’t get into-you can read the Dossier for those. These periods are lifesavers for intermediate Pac-Man players playing without patterns, as they are the only really safe ways to access the bottom passages of the board without getting trapped or wasting an Energizer.

Each Scatter Mode is only supposed to last five-to-seven seconds, but on Level 22 and after, all of the Scatter Modes last around 20 seconds. Here is the bug in action, demonstrated in Namco Museum Archives Vol. 1:

Why would this board be different from the others? In the arcade, the 9th Key (Level 21) is the maximum difficulty the game reaches. Any pattern that works on the 9th Key level will work for the rest of the game, all the way up to the kill screen on Level 256. It seems that, on the Famicom/NES version, after that level the game may not have data for the level to follow? But I haven’t looked at its code to know for sure. Maybe I should make that a future project.

NES and Commodore 64 Games Compared

Greg’s Game Room on Youtube looked at 28 games with both NES and Commodore 64 versions. It’s not by any means all of them, but a good selection. Usually its the NES version that’s better, but there are some surprising upsets, especially if the game originated on a microcomputer platform.

The Commodore games that won out are Ballblazer, Castelian, Die Hard (but the C64 version’s really different), Ghostbusters, Ghosts ‘n’ Goblins, Q*Bert and (surprisingly) Smash T.V. Decent C64 games that nevertheless lost are Blades of Steel, Commando, Donkey Kong, Mighty Bomb Jack and Super Mario Bros. (rated were both the similar Great Giana Sisters and the recent fanmade version of SMB that uses advanced scrolling tricks). Gyruss, Mario Bros. and Pac-Man were rated at a tie.

Nintendo vs Commodore 64, 28 Games Compared (Youtube, 46 minutes)

Famicom Family BASIC

I love BASIC! I don’t make a secret of it. It was the product, even before DOS, that launched Microsoft. It was invented to be the language to bring programming to the masses, and, for a short time, it fulfilled that function. (These days, if you want to learn coding, I suggest Python. Not only is it a lot more capable and modern, but you can actually get a job writing it.)

Used to be if you had a new computer you wanted families to buy, you had to have a version of BASIC to ship with it. The Apple II had two, one written by Steve Wozniak himself. Right off the top of my head, computer systems with BASIC, go! Altair, Apple II, Commodore Pet, Vic-20, 64, 128, Plus-4, 16, Atari 8-bit, TRS-80, MS-DOS, Windows (Visual BASIC carried the torch for many years), and, most improbably, the Atari VCS/2600, in its BASIC Programming cartridge, an effectively useless cart for its stated purpose that’s nonetheless an excellent hack. The machine has 128 bytes of RAM, but it can still run BASIC, by jove.

The Famicom has a version of BASIC too, coming in at the end of the language’s heyday. Over on the Peertube instance diode.zone, user RE:Enthused did a two-part introduction to it that may be of interested to people who still think in terms of FOR/NEXT loops.

Let’s look at Family Basic on the Famicom, Part 1 (8 minutes) and Part 2 (17 minutes).

Kid Fenris on Wurm

Wurm: Journey to the Center of the Earth is a Famicom/NES title with a lot of ambition, perhaps too much. Over on his self-named blog Kid Fenris posted a long article on it back in March. It makes it seem a lot more interesting than it otherwise would! We at Set Side B love experiments, successful or failed, and Wurm certainly was one, with shooter, side-scrolling platformer, first-person boss fights and even some visual novel elements. And protagonist lady named “Moby” is searching for her boyfriend named “Ziggy.”

Green-haired Moby wears the kind of outfit you could only find in something inspired by 80s anime.

The post mentions that designer Shouichi Yoshikawa, a.k.a. “Angela,” has an interview up at GDRI. It also mentions that Angela used to have a site devoted to their game, which while gone now has a backup on the Wayback Machine! Sadly the promised English version of the site never materialized.

Also–Kid Fenris mentions he once wrote about Wurm on GameSetWatch. My old stomping grounds!

Kid Fenris: Journey to the Center of Wurm

Behind the Code: About the NES’ Sprite Capabilities

Displaced Gamers‘ Behind the Code series doesn’t get new videos often, but they’re always great. This one is more technical than usual, but I don’t think it’s really all that technical. It’s about how the NES processes and renders its sprites, particularly explains why there’s a eight sprite per scanline limit, and even reveals a couple of games that use that limit to produce special effects!

The gist: while each scanline is being prepared for display, the NES’ PPU looks through the entries for the machine’s 64 hardware sprites in order, finds the first eight that will display on the current line, and copies their attribute data to a small area of internal RAM. There is only space there for eight sprites, so, the NES cannot display more than eight sprites in a single scan line. Any later sprites in the primary attribute data won’t have room to be copied, and so the PPU won’t be able to display them.

One thing it notably doesn’t cover, however, is how games implement priority shuffling to cause sprites to flicker instead of not display at all. The video suggests that that might be coming in a future video….

NES Sprites, OAM, and the Battle for Priority – Behind the Code (Youtube, 19 minutes)