📰 newsreader

twostopbits score 0.09 好み 0.00 en

C64版Omega Race — 2つのカートリッジの物語 (masswerk.at)

原題: Omega Race on the C64 — A Tale of Two Cartridges (masswerk.at)

commodore 64ultimaxomega racecartridgememory mapping6510 cpuromcartridge port
原文 ↗

日本語訳

# タイトル

C64におけるOmega Race — 2つのカートリッジの物語

# 本文

C64におけるOmega Race — 2つのカートリッジの物語

奇妙な重複を、文字通りに紐解いていく。

以前、ゲーム「Omega Race」のUltimax用カートリッジが存在すること、それがCommodore C64でプレイ可能であること、そしてそれがこの種のカートリッジにおけるフォントデータの意図的な埋め込みをどのように示しているかについて、簡単に触れました。

それは確かに知っておくべき良い情報ですし、その事実を明らかにできたことを嬉しく思っています。……さて……うーん……しかし、待ってください。これだけではありません。実は、C64には「Omega Race」のカートリッジが、実に2種類存在するのです!

一つは先述のUltimaxカートリッジ、そしてもう一つは、C64専用のカートリッジも存在するのです。

C64はUltimaxカートリッジを標準状態で極めて完璧に動作させることができ、両方のカートリッジのROMサイズも8Kと似通っているため、これは少し不可解に思えるかもしれません。なぜわざわざこのような方法をとったのでしょうか? 単一のユニバーサルなフォーマットに統一すればよいはずです。

さて、これについては詳しく調査してみるほかありません。今回は、文字通り「詳しく」見ていきましょう。

しかし、その前に、案の定、これについても見ておく必要があります……。

### C64カートリッジ動作の細部

C64のカートリッジを説明するには、最初から、つまり、マシンの電源を入れるところから始めなければなりません。電源を入れると、単純なタイミング回路が、システム全体に電力が供給され各コンポーネントが安定した状態になるまで、特定のピンの信号をLow(GND)に引き込むことで、CPUを数瞬の間、リセット状態に保持します。次に、CPUのリセットラインがHigh(+5V)になり、CPUが「リセットから抜ける」ことで通常の動作が開始されると、CPUは$FFFCと$FFFD(下位バイト、上位バイト)にあるハードコードされた特定の、RESETベクトルと呼ばれるアドレスを検査し、これら2つのメモリ位置に指定されたアドレスにあるコードの実行を開始します。これにより、信頼できる、定義済みでありながら構成可能なスタートアップ・シーケンスが確立されます。

では、これらのアドレスには何があるのでしょうか? C64のROMです。簡単ですね! ……と言いたいところですが、そうとは限りません。状況によります。より正確には、カートリッジポートにある信号によって決まります。

C64のカートリッジポートには、今回の文脈において重要となる2つの信号があります。それが「`_GAME`」と「「`_XROM`」です。もし `_XROM` がLow(0: GND)で、`_GAME` がHigh(1: +5V)であれば、C64はUltimaxモードとして構成されます。

#### Ultimax

では、Ultimaxとは一体何者なのでしょうか? Commodore Max、日本での名称は「Commodore Max Machine」、アメリカでは「Ultimax」、ドイツでは「VC-10」(発表されたが未発売)として知られるマシンは、ビデオゲームのプレイに特化した低予算マシンを目指した、Commodoreによる短命な試みでした。C64と同時期に開発され、コアコンポーネントも共有していました。すなわち、6510 CPU、グラフィックス用のVIC II、サウンド用のSIDです。しかし、ユーザーポートやシリアルポートといった不可欠な通信ポートをコスト削減のために欠いていたため、CIAは1つしか搭載されていませんでした。また、RAMはわずか4Kで、ROMは一切搭載されておらず、その動作は完全にカートリッジに依存していました。まさに、競合他社を圧倒し、打ち負かし、歌い上げ、そして最後には……売上でも圧倒するために。後者については、[Ulti]Max [Machine]™が導入されたのと同じ年に製造中止となったため、あまり成果は上がりませんでした。

(興味深い余談として、ドイツではMaxはC64と共に発表されました。ドイツでは、製品ラインナップの両端に、名機VC-20(ドイツ版では、アメリカでPuck-ManがPac-Manになったのと同様の理由で名前から「I」が消えました)を挟む形で、MaxはVC-10、C64はVC-40として位置づけられていました。この並行したマーケティングの取り組みは、C64と[Ulti]Max [Machine]™がいかに、Atari 400とAtプリ800のように、密接に連携して展開される予定だったかを物語っています。アメリカ向けの2つのマシンのパンフレットも、同様のスタイルと雰囲気を持っており、並行した取り組みを強調しています。)

RAM、ROM、そしてフルトラベル・キーボードは、ホームコンピュータ製造の総コストに大きく寄与するため、[Ulti]Max [Machine]™は予算を効果的に削減するために最善を尽くしました。

そのため、Ultimaxは以下のメモリマップを備えています。

```

$0000-$0FFF .... RAM (4K) 内部

$1000-$3FFF .... -

$4000-$7FFF .... -

$8000-$9FFF .... ROML (8K) 外部

$A000-$BFFF .... -

$C000-$CFFF .... -

$D000-$DFFF .... I/O

$E000-$FFFF .... ROMH (8K) 外部

```

これは、カートリッジポートで `_XROM` がLow、`_GAME` がHigh(通常状態)として検出された際のC64の構成と全く同じです。これは完全にハードウェアによるものです。CPUがリセットから抜ける際、$FFFCにあるRESETベクトルとして認識するものは、カートリッジのROMです。この時点で、事態は決定しており、C64は「Max Machine」となっているのです。

カートリッジポートには2つの信号があり、それによってマシンは、2つの可能なROMバンクのうちどちらをアドレス指定しているか(上記の `_ROML` と `_ROMH`)を指示できます。しかし、CPUが正常に起動するためにはRESETベクトルを見つける必要があるため、必然的に $E000 から $FFFF にある ROMH バンクの8Kがデフォルトとなります。これが、すべてのUltimaxカートリッジが行っていることです。

覚えておくべき重要な点は、このモードにおいて、C組み込みのROMは一切利用できず、RAMの大部分も失われ(わずか4Kしか残らない)、Ultimaxと同様にカートリッジROMのみに依存しなければならないということです。なぜなら、それは単にUltimaxのように振る舞うだけでなく、文字通り「もう一つのUltimax」そのものだからです。

(以前、C64の診断用カートリッジである「Dead Test」が、組み込みROMを一切使わずに(Ultimaxモードではそれらは実質的に見えなくなります)どのように動作するかを見てきました。しかし、これには、全64Kのメモリのうち下位の4Kしか「見えない」という代償も伴います。カートリッジ内のROMバンクを選択するための、普段はほとんど使用されない2つの信号は、また、このカートリッジに $8000 にコードを持つ拡張リビジョンが存在し得た理由も説明しています。)

#### C64ゲームカートリッジ

`_GAME` がLow(0: GND)で、`_XROM` がHigh(1: +5V)の場合、話は全く別になります。この場合、扱っているのはC64ゲームカートリッジです。マシンは標準的なC64のメモリレイアウトとして通常通り構成されますが、唯一の違いは、カートリッジROMが $8000 から $9FFF のアドレス範囲に露出されることです。ハードウェアが行うのは、通常これらのアドレスにある組み込みRAMの代わりに、カートリッジROMをこのメモリ範囲に挿入することだけです。

これは、カートリッジの起動プロセスが、この場合にはソフトウェアに依存しなければならないことも意味します。

CPUが「見る」のは、Kernal ROMにある通常のRESETベクトルであり、以下のプロセスを辿ることになります。

| C64 リセットシーケンス | アドレス | コード | ディスアセンブル | コメント |

| :--- | :--- | :--- | :--- | :--- |

| | FFFC: | E2 FC | ; RESETベクトル: $FCE2 | |

| | FCE2 | A2 FF | LDX #$FF | スタックポインタの値 |

| | FCE4 | 78 | SEI | 割り込みを無効化 |

| | FCE5 | 9A | TXS | スタックポインタを初期化 |

| | FCE6 | D8 | CLD | BCDモードをクリア |

| | FCE7 | 20 02 | JSR $FD02 | $8000のオートスタートROMをチェック |

| | FCEA | D0 03 | BNE $FCEF | 見つからない場合はスキップ... |

| | FCEC | 6C 00 80 | JMP ($8000) | カートリッジ・コールドスタート・ベクトル |

| | FCEF | ... | ↓ | |

| | FD02 | A2 05 | LDX #$05 | $8004の文字列 "CBM80" をチェック |

| | FD04 | BD 0F FD | LDA $FD0F,X | $FD10の5バイトを$8004と比較 |

| | FD07 | DD 03 80 | CMP $8003,X | |

| | FD0A | D0 03 | BNE $FD0F | 一致しなければ終了へスキップ |

| | FD0C | CA | DEX | |

| | FD0D | D0 F5 | BNE $FD04 | ループ (X: 5..1) |

| | FD0F | 60 | RTS | ゼロフラグで状態を返す (0: 発見) |

| | ↵ FD10: | C3 C2 CD 38 30 | | CBM80 |

$FFFC のRESETベクトルは $FCE2 を指しており、そこで6510プロセッサはコードの実行を開始します。まず、256バイトのスタックのトップを指すように、プロセッサのスタックポインタを初期化するための値をXレジスタにロードします。次に、「i」(割り込み禁止)フラグをセットすることで、いかなる割り込みリクエスト(IRQ)によっても妨げられないようにします。

(真の通な方なら、なぜここから始めなかったのかと疑問に思うかもしれません。実は、このコードの元となったPETのROMには、開始シーケンスのどこにも `SEI` 命令が存在しないのです。ですので、これでも無いよりはマシ、ということでしょう。とはいえ……)

とにかく、スタックポインタ(SP)をセットし、通常のバイナリ演算のためにデシマルフラグをクリアすることで、処理を続行します。これにより、必須の操作を行うための準備が整います。コードが最初に行うのは、$FD02 のサブルーチンへの分岐です。ここでは、$8004のアドレスから始まる5バイトが、大文字のPETSCII形式の「魔法の文字列」である "CBM80" と比較されます。

原文(英語)を表示

Omega Race on the C64 — A Tale of Two Cartridges

A quite literal look into a curious duplication.

Ppreviously, we briefly mentioned that there was a Ultimax cartridge of the game “Omega Race”, that this was playable on the Commodore C64, and how this demonstrated the rather deliberate embedding of font data in this type of cartridge.

So that’s certainly good to know and we’re quite glad to have established that. … Well… Hmm… But wait, this is by no means all: there are actually two “Omega Race” cartridges for the C64!

Once said Ultimax cartridge and then there is a dedicated C64 cartridge, as well.

Since the C64 plays Ultimax cartridges quite perfectly out-of-the-box and both cartridges are similar in ROM size, 8K, this may be somewhat puzzling. Why even bother doing it this way and not just go with a single, universal format?

Well, what is there to do, but having a closer look at this. This time, quite literally so.

But before we do this, we have, you guessed it, to have still a look at…

The Nitty-Gritty Details of C64 Cartridge Operations

In order to explain cartridges for the C64, we have to start at the very beginning. As in turning on the machine. What happens then is that a simple timing circuit puts the CPU a few moment in a reset state, by pulling the signal on a special pin low (to GND), until power has distributed through the system and the various components are in a stable state. Next thing, as the reset line on the CPU goes high (+5V), indicating normal operations, as the CPU is said “to come out of reset”, the CPU inspects a certain hard-coded address, the RESET vector at $FFFC and $FFFD (low byte, high byte), and starts to execute whatever code there is at the address given in these two memory locations. This way, we have a well-defined, but still configurable, start-up sequence, which we can rely on.

So, what’s at these addresses? The C64 ROM, easy! Well, it may be, but it may be also not. It depends. More precisely, it depends on the signals found at the cartridge port.

The cartridge port of the C64 features two signals, which should be interesting to us in this context: “_GAME

” and “_XROM

”. If _XROM

is low (0: GND) and _GAME

is high (1: +5V), the C64 configures in Ultimax mode.

Ultimax

So who or what is a Ultimax? Well, the Commodore Max, AKA Commodore Max Machine (in Japan), or Ultimax (in the USA), or VC-10 (in Germany, announced but never released), was a short-lived attempt by Commodore on a low-butget machine geared towards playing video games. It was developed at the same time as the C64 and shared its core components: the 6510 CPU, the VIC II for graphics, the SID for sound, but, since it cost-effectively lacked the essential communication ports like the user port or the serial port, it came with just a single CIA. Also, it had just 4K of RAM and no ROM, at all, relying entirely on cartridges for its operations. Namely, for out-zonking, out-zapping, out-singing and — last but not least — out-selling the competition. Not much became of the latter as the [Ulti]Max [Machine]™ was discontinued the same year that saw its introduction.

(As a maybe interesting aside, in Germany the Max was announced together with the C64, the Max featuring as the VC-10 and the C64 as the VC-40, bracketing at both sides of the product lineup the venerable VC-20, which in its German incarnation lost the “I” in its name for much the same reasons that Puck-Man became Pac-Man in the USA. This parallel marketing effort may illustrate how the C64 and the [Ulti]Max [Machine]™ were really meant to go in tandem, much like the Atari 400 and the Atari 800. Even the US pamphlets for the two machines share a similar style and mood, emphasizing the parallel effort.)

With RAM, ROM, and fullt-travel keyboards contributing significantly to overall costs of home computer production, the [Ulti]Max [Machine]™ did its best to reduce its budget effictively.

Thus, the Ultimax features the following memory map:

$0000-$0FFF .... RAM (4K) internal $1000-$3FFF .... - $4000-$7FFF .... - $8000-$9FFF .... ROML (8K) external $A000-$BFFF .... - $C000-$CFFF .... - $D000-$DFFF .... I/O $E000-$FFFF .... ROMH (8K) external

which is exactly how the C64 configures when a low _XROM

signal and a high (normal) _GAME

signal is detected at the cartridge port. This is entirely a hardware thing. As the CPU comes out of reset, what it will see as the RESET vector at $FFFC is the cartridge ROM. At this point, it’s already a fait accompli, the C64 is a Max Machine.

Mind that there are two signals at the cartridge port, which allow the machine to signal which one of the two possible ROM banks it is addressing (_ROML

and _ROMH

, see above). But, since the CPU has to find a RESET vector in order to start successfully, this necessarily defaults to the 8K in the ROMH bank at $E000 to $FFFF. Which is what all the Ultimax cartridges do.

The important part to be kept in mind is really that, in this mode, the C64 has none of its built-in ROM available and lost most of its RAM (with just 4K remaining), and, just like the Ultimax, has to rely on the cartridge ROM alone, because it doesn’t just behave like the Ultimax, it really is another Ultimax.

(Previously, we saw that this is how the “Dead Test” diagnostic cartridge for the C64 manages without any of the built-in ROMs (they are really invisible in Ultimax mode). But this comes also at the price of “seeing” just the lowest 4K out of the total 64K of memory. The two signals for selecting the in-cartridge ROM banks, otherwise mostly unused, also explain how there could have been an extended revision of this cartridge with code at $8000.)

C64 Game Cartridges

When _GAME

is low (0: GND) and _XROM

is high (1: +5V), the story is an entirely different one. In this case, we’re dealing with a C64 game cartridge. The machine will be configured as normal, to standard C64 memory layout, the single difference being that the cartridge ROM will be exposed in the 8K address range from $8000 to $9FFF. All, the hardware does, is inserting the cartridge ROM in this memory range instead of the built-in RAM that is normally found at these addresses.

This also means that the start-up process for a cartridge must rely in this instance on software.

What the CPU “sees” is the usual RESET vector in the Kernal ROM, and we’ll have to follow this:

C64 Reset Sequence addr code disassembly comments FFFC: E2 FC ;RESET vector: $FCE2 ↓ FCE2 A2 FF LDX #$FF ;value for satck pointer FCE4 78 SEI ;disable interrupts FCE5 9A TXS ;initialize stack pointer FCE6 D8 CLD ;clear BCD mode FCE7 20 02 FD JSR $FD02 ;check for autostart ROM at $8000 FCEA D0 03 BNE $FCEF ;not found? skip... FCEC 6C 00 80 JMP ($8000) ;cartridge cold start vector FCEF ... ↓ FD02 A2 05 LDX #$05 ;check for string "CBM80" at $8004 FD04 BD 0F FD LDA $FD0F,X ;compare 5 bytes at $FD10 to $8004 FD07 DD 03 80 CMP $8003,X FD0A D0 03 BNE $FD0F ;no match, skip to exit FD0C CA DEX FD0D D0 F5 BNE $FD04 ;loop (X: 5..1) FD0F 60 RTS ;return state in zero flag (0: found) ↵ FD10: C3 C2 CD 38 30 ;CBM80

The RESET vector at $FFFC points to $FCE2, where the 6510 processor will start executing code. This first loads the value for initializing the processor’s stack pointer into the X register, to point to the top of the 256-byte stack. Then, we make sure that we’re not disturbed by any interrupt request (IRQ) by setting the “i” (interrupt disable) flag.

(A true connoisseur may ask why we didn’t begin with this. Well, the ROM of the PET, which this code was derived from, doesn’t feature any SEI

instruction, at all, nowhere in the start sequence. So, I guess, this is better than nothing. Still…)

Anyway, we continue by setting the stack pointer (SP) and clear the decimal flag for normal, binary arithmetics. By this, we’re set up for essential operations and ready to go. The first thing, the code does, is to divert to a subroutine at $FD02. Here, the 5 bytes starting at address $8004 are compared to the ‘magic’ string “CBM80

” in upper-case PETSCII. This routine returns with the result in the zero flag. If it is unset (clear), we found the string and jump to the address found in $8000 and $8001 (low-byte, high-byte) by an indirect jump.

Conversely, this is what the very start of the ROM in a C64 game cartridge looks like (here “Omega Race”):

8000: 09 80 ;cold start vector: $8009 8002: D8 80 ;warm start vector: $80D8 8004: C3 C2 CD 38 30 ;CBM80 8009: ...

The important part here is that this is still a normal C64, it‘s just that the ROM is made available instantly in the address range. However, in case it’s an autostart cartridge with the magic string “CBM80

” at $8004, the cartridge has to bootstrap on its own, has to stand on its own feet: while the built-in ROMs and their various routines will be still available, as is the character ROM, the remainder of the start sequence and the initialization of the machine is left to the cartridge code.

So, you may ask, what if both _GAME

and _XROM

are low? Well, then it’s a 16K C64 cartridge and 16K of cartridge ROM will be exposed at $8000–$BFFF (ROML

at $8000–$9FFF, ROMH

at $A000–$BFFF). Since only the very beginning of any ROM (at $8000) matters for the start sequence, this works just the same with 16K cartridges.

Omega Race, ×2

Now that we know this, how the games come onto the C64 and what this implies, we may have actually some fun with them!

So, let’s have a look, quite literally. For a difference, we won’t inspect hex-dumps or disassemblies of the code, we just look at it, in a visualization of the last (top) 2K of the ROM, where most of the game data resides. Let’s begin with the Ultimax version, visualizing the ROM from $F800 to $FFFF, lined up in neat little blocks of 8 bytes, each, left to right, top to bottom.

We may immediately discern the character data for the font, illustrating that in Ultimax mode there is no true or conventional order to characters, as this is neither in PETSCII nor in Commodore screen code order. Rather, relying on its own drawing routines, the cartridge does its own thing. The font is mostly identical to the standard C64 font, but features special stylized versions of the figure “9” and the letter “P” (each missing a pixel — this isn‘t a fluke in the ROM image, I actually do remember the peculiar “9” from back in the day).

This is followed by special characters to indicate function keys, followed by graphics for the borders and central box, a ship indicator and the “android” ships. This is in turn followed by various tables of game data, and (I believe) some actual code at the end. (The last 6 bytes are the CPU vectors, all 3 pointing to $E000, with the RESET vector second to last.)

And here‘s the dedicated C64 version of the game:

Since the dedicated C64 version of the game can make use of the internal character ROM, there is no need for alphabetic font data. Instead, there’s some (additional) code and/or data. But then we see some similarities to the Ultimax version: the characters (, ), − and ;. Adjacent to this, there are some very special characters, apparently for a stylized title. Then, the graphics data is mostly the same, with another title character in place of the upright ship icon (which seems to go unused in the Ultimax game.) Even the game data is apparently much the same. There are some additional data blocks, though, both in “holes” (or blank spaces) in the data for the ship graphics and filling some spaces in the data section, which were empty in the Ultimax version.

We can overlap the tow images to see the differences:

We may immediately grasp that these are essentially the same game. There are a few differences in the data/code section at the very end, which can be attributed to differences in addresses and referrring to different routines. But there are also these additional data blocks in the C64 version, for the most spread over the “holes” in the graphics data.

Some if not most of this is related to differences in sound: the C64 version attempts to show off the capapilities of the SID by a resonant, but also quite repetitive android sound, which is, frankly speaking, rather annoying. The Ultimax version does with a simpler, unfiltered sound, which may be also a bit more pleasant. Personal preferences aside, the C64 version requires additional tables for filter data and so on, in order to achieve its more complex soundscape.

And, indeed, gameplay-wise, the two cartridges do play very much the same. The only difference being that the Ultimax version surprises with a color cycling effect during any explosions of the player’s ship, where the C64 does not. It’s rather impressive that the “bare metal” Ultimax version, which can’t rely on any built-in ROM routines and requires additional embedded font data manages to do the same as the dedicated C64 version. Conversely, it may be a bit disappointing, that the C64 version doesn’t achieve more, even with the additonal ROM space spent, where the Ultimax cartridge has its embedded alphanumeric font data.

BTW, regarding embedded font data, it’s kind of interesting that there should be those redundant characters (, ), − and ; embedded in the C64 version. These are already in the character ROM! Conversely, we find the redundant repetition of the figures 0 and 1 in the Ultimax version of the game, just adjacent to this. Raising the question, which one actually came first?

- Were the additonal data tables (for more elaborate sound, etc.) omitted in the Ultimax version, which also puts its special function key graphings in place of the stylized title characters, filling the remaining two character spaces by a repetition of 0 and 1? Were this changes in sound and title graphics correcting elements of the game that weren’t deemed a great success?

- Was the C64 version squeezing in additional data, patching the code wherever there was some space left, by this also overwriting some of the more fancy, but not absolutely crucial character data in favor of a stylized titel?

- Or was this a shared codebase, with both types of machine in mind, right from the beginning?

(BTW, said “holes” in the character data may probably be attributed to the internal data layout so that animation phases and display types may be addressed by index, just using simple shifts and ORs.)

Speaking of the title screen, this is where we actually find visual differences in the two versions of the game:

The title screen of the C64 version is somewhat bland and wasn’t received well. There’s just a plain list of options for the input mode and background and foreground colors, and, yes, at least some color in the stylized title. However, as far as stylized titles go — and in order to understand why this may have been disappointing —, just compare this to the VIC-20 cartridge, also © 1982:

That’s a stylized title! Given the much advertised capabilities of the VIC’s “big brother” this was more of a down-grade and certainly not inspiring.

And here’s the title screen of the Ultimax cartridge:

There are a few things of note:

- Firstly, as should be instantly apparent, it uses a different color scheme with dark blue characters on a bright background. Unless you select different colors, this carries over to the actual game.

(It can’t be said if this is for personal taste of those in charge or maybe in an effort to match the bright-silvery case of the machine, or if this was done to differentiate the two versions of the game, with the colorful title reserved for the more powerful C64 as an “upgrade”.) - Then, there is no title. The game isn’t just missing a stylized title, there is no title at all on this title screen. Even more so, there is no title in the game whatsoever: nowhere in the game does it say “Omega Race” even once!

(As for Commodore, we could as well be playing Space Invaders or some other game.) - The game makes kind of good for this by the use of the stylized function key indicators, which provide some style and structure to the otherwise unaltered options list.

- The credit for Bally Midway is missing. (Is this due to memory constraints? Or is it an esthetic choice?)

- Finally, the Commodore credit reads “©1982 COMMODORE ELEC. LTD. V02” instead of “© 1982 COMMODORE LTD.” in the C64 version. (Commodore Electronics Ltd. was a major subsidiary of Commodore International Ltd., under which most Commodore games were published.)

- Moreover, it can’t be said (or, at least, it isn’t immediately apparent) what “V02” refers to exactly: is it the second revision of the Ultimax cartridge, does this mean that the C64 version was first and this was the second version, or does this refer to the VIC version, also featuring 1982 in its copyright message, as the original version?

For a convenient comparison, here are the two start/title screens side-by-side:

The Ultimax screen certainly makes for a more sophisticated appearance by the structure added by the stylized F-key indicators. The C64 version, while otherwise rather bland, makes at least some attempt on an actual title for the game.

However, to understand what’s really going on here, we must have a look at…

Omega Race for the VIC-20

The VIC-20 version of the game, also released on cartridge (VIC-1924) and also bearing a copyright date of 1982, was a remarkable and much acclaimed arcade port, still figuring as one of the top-10 games on the platform to this day.

Now have a look at the title screen of the VIC version. It isn’t just a title screen, it’s an entire title sequence consisting of 5 individual screen cycling in a loop:

• #1 – The actual title (as we‘ve seen, this isn‘t to be taken for granted):

• #2 – Game options, the function key markers in reverse video blink and cycle in color (this is the equivalent to the start screen of the C64 and Ultimax versions):

• #3 – We actually get a story (this is taken directly from the 1981 arcade game):

• #4 – For the true arcade feeling, we even get a scoring table:

• #5 – Finally, the story continues:

This is even more remarkable, since the VIC version manages to squeeze all this into just the same amount of 8K ROM that’s available to the C64 and Ultimax versions!

There‘s also a feature found in the VIC version that‘s missing in the C64 and Ultimax versions: when holding the SHIFT key while pressing the respective function key to start a game either with joystick or paddle controls, you get 5 instead of the usual 3 ships/lives. On the other hand, the VIC version is lacking an option for keyboard controls.

With regard to this, both the dedicated C64 version and the Ultimax version are restrained to just the options screen, dropping the note on the bonus ships for the indispensable copyright message(s). While the Ultimax version preserves the stylized F-key markers (less the blink and color-cycle effect), the C64 rather decides to have an attempt at the title. (You can’t have both, this would be preposterous! Just pick one!) However, rather than going for the actual logo (maybe using sprites?), similar to the VIC version, we get just a blocky line of text. — Well, it‘s a much more powerful machine and we can’t just recklessly let loose these powers unrestrained and out of control…

As for our initial question, it’s still hard to tell from this which version may be closer to an original idea and/or concept. However, it really doesn‘t make much sense to come up with a dedicated C64 version when you‘re just releasing a system with some notable effort and investment involved to run the same cartridges on both the C64 and the [Ulti]Max [Machine]™. Which may suggest that the dedicated C64 version should have come first. (Which would make the changes in the start screen even more remarkable, since the the Ultimax version could probably have just gone the same with some kind of title display instead of the stylized F-key markers, in the same memory constraints.) But, just the same, it could be that both versions were developed at once with a shared code base. Which would render some of the decisions even more puzzling.

Anyhow, just in case you wouldn‘t know, here is what the actual game looks like:

← 一覧に戻る