Coin-Op Collection Present: Capcom Play System (Netlist), Batrider: Chase!, & Guwange OMEN
Today's release differs from anything we've done before. This beta for the Analogue Pocket and MiSTerFPGA platforms brings us the CP System, or CPS-1, the arcade hardware Capcom introduced in 1988, along with every commercial title released on it from 1988 to 1995.
Every chip that runs these titles has been rebuilt from the silicon itself, working from the dies and netlists instead of emulation, with the exception of the MSM6295, for which no die shot is available. The MSM6295 is instead built to OKI's own datasheet and voice synthesis LSI data books, which document its ADPCM synthesis, channel handling and timing. The MSM6295 implementation was cross-referenced and measured against the chip itself.
Below are the CPS-1 titles supported in this release:
Lost Worlds / Forgotten Worlds (1988)
Daimakaimura / Ghouls'n Ghosts (1988)
Strider Hiryu / Strider (1989)
Tenchi wo Kurau / Dynasty Wars (1989)
Willow (1989)
Area 88 / U.N. Squadron (1989)
Final Fight (1989)
1941: Counter Attack (1990)
Senjou no Ookami II / Mercs (1990)
Chiki Chiki Boys / Mega Twins (1990)
Magic Sword: Heroic Fantasy (1990)
U.S. Navy / Carrier Air Wing (1990)
Nemo (1990)
Street Fighter II: The World Warrior (1991)
Wonder 3 / Three Wonders (1991)
The King of Dragons (1991)
Knights of the Round (1991)
Captain Commando (1991)
Street Fighter II': Champion Edition (1992)
Adventure Quiz Capcom World 2 (1992)
Quiz & Dragons: Capcom Quiz Game (1992)
Varth: Operation Thunderstorm (1992)
Street Fighter II' Turbo: Hyper Fighting / Street Fighter II': Hyper Fighting (1992)
Pnickies (1994)
Quiz Tonosama no Yabou 2: Zenkoku-ban (1995)
Pang! 3: Kaitou Tachi no Karei na Gogo / Pang! 3 (1995)
Rockman: The Power Battle / Mega Man: The Power Battle (1995)
How all this started goes back to the Data East platforms I've been working on for the past year and a half. To stand up the DECO platforms properly, I perfected a custom, specialized vision model, along with tooling, that assists in tracing die photographs and produces workable netlists in Verilog. The Capcom work began as a byproduct of testing them. I never intended to release the Capcom work, but with the Data East platforms as saturated as they've become, I'm releasing it as a proof of concept for the model while continuing to work on Data East, Toaplan, and other platforms.
The two Capcom custom ASICs that draw graphics in every game, the CPS-A (DL-0311) and the CPS-B (DL-0921), started as die traces. With the model, I expanded on Loic Petit's work, retracing both ASICs and turning them into gate-level netlists, then simulated both chips together on the 89626A-4 DASH A-board and the 91634B-2 B-board, reproduced from in-house schematic extraction. Where the traces carried drawing errors, crossed buses, swapped pads or the wrong gate in a cell, I corrected the netlists until both chips drew real game frames, and the corrections held up against photographs of the dies.
The 68000 used in the cores is my own, built from its die. It runs the MC68000's microcode, read bit for bit from the ROM arrays on the die, with its instruction decode generated from the die's netlist, and this is its first release. The Z80 used in the cores is also my own, built from its die, following the transistor netlist of the NMOS part on every documented and undocumented instruction, T-state by T-state, and unlike the microcoded open-source core most projects use today, it contains no microcode.
The board-level logic comes from schematic extraction done on my Street Fighter II' Turbo: Hyper Fighting board set, the 89626A-4 DASH A-board, the 91634B-2 B-board and the 92631C-B C-board, along with the fuse maps of every PAL on the A-, B- and C-boards and the resistor values and timings measured on the PCB.
This post covers a technical overview of the Capcom Play System, the work the platform required, the core options, and the history of the hardware. Below are the dies of all four chips:
Over the coming weeks, I'll be open-sourcing some of the work behind this release. I'll publish the gate-level netlists of the CPS-A and the CPS-B myself and submit them as pull requests to Loic Petit's repository, and the full schematic extraction of the A-, B- and C-boards taken from my Street Fighter II' Turbo: Hyper Fighting PCB will follow after a final verification sweep, when time permits.
Credits and Acknowledgments:
Pramod Somashekar (pram0d): additional hardware measurements beyond Street Fighter II': Hyper Fighting / Ghouls'n Ghosts, designing TL866 flash ROM alternatives for additional validation, and testing/validation of the CPS-1 cores
Brandon Arnold: die-trace tooling and assistance building the cell library used to identify the NMOS and CMOS gates on the dies
Loic Petit (WydD): the original CPS-A and CPS-B die traces this work expanded on
Eduardo Cruz (ArcadeHacker): the CPS-B-21 configuration research and the keys used in the gate-level simulation
Undamned: InfiniKey-CPS1, the complete CPS-B-21 configuration keys with their check values
originalgrego: the SF2 DMA test, adapted for this work into the SF2 DMA Test ROM for an sf2eb (World 910214) board and used for the CPS-A bus-timing measurements
John McMaster: access to his unpublished CPS-B (DL-0921) die photographs and authorization to release them publicly in full with this work, along with the MC68000 die photographs
Olivier Galibert: the MC68000 die layer extraction the 68000 netlist is based on, retraced, expanded, and corrected for this work
Visual Z80 (Pavel Zima's Z80Simulator, with layer polygons by David Banks): the NMOS Z80 die photograph and layer data the Z80 netlist is based on, retraced, expanded, and corrected for this work
Sehyeon Kim (Raki): IKAOPM, the die-based YM2151 used in the cores, and ASIC_RE, his open-source gate array reverse-engineering references
Licensing:
The CPS-1 cores are distributed through the Coin-Op Collection licensing portal, which serves both MiSTerFPGA and Pocket from the same dashboard. Patrons need to register their device and generate a key before launching the cores. Registration uses the ChipID utility, which shows your device's Hardware ID as a QR code you scan with your phone, and each account covers one MiSTer and one Pocket by default. Step-by-step instructions and the FAQ are available on the Help page.
Keys are tied to your Patreon subscription and are generated on the 2nd of each month, while yearly subscribers' keys run until the end of their subscription. On MiSTerFPGA, Update All downloads and renews the key automatically for RetroAccount members. On the Analogue Pocket, pupdate downloads and renews the key automatically on every update run.
The cores are a beta release. On MiSTerFPGA, automatic key installation through Update All requires a RetroAccount membership. As a RetroAccount member, register your MiSTer on the licensing portal, then log in from the Update All Settings Screen and link your FPGA ID from the Account section. Update All installs the key and renews it automatically.
The Coin-Op Collection submenu has options for Public, Beta and Alpha releases, following your Patreon tier by default and replacing the downloader.ini edit from earlier posts. The full walkthrough is in the Update All 2.11 post here. If you are not a RetroAccount member, you can manually set your tier.
For the Analogue Pocket, pupdate fetches the key for you. Turn on the Coin-Op Collection auto-fetch option under Accounts in pupdate's settings. pupdate reads your Hardware ID from the .ID file at the root of the SD card, downloads coinop.key on every update run and copies it to each core that needs it. If there is no .ID file, pupdate asks for the 16-character Hardware ID shown on the portal and saves the file once the key downloads.
The MRA files for this release carry a [CoC] ending, such as Street Fighter II - Hyper Fighting (World 921209) [CoC], because other CPS-1 cores are available on MiSTerFPGA, and the ending keeps ours apart from the others in the arcade menu. On the Analogue Pocket, the cores and their ROM files carry a coc. prefix, such as coc.sf2hf.rom, so they never collide with the files other Pocket cores use for the same games.
Overview:
The CP System runs on a three-board set. The A-board carries the main and sound processors, the sound section, the CPS-A and the video RAM, and it stays the same across the platform apart from its revisions, from the original 88617A to the 89626A-3, 89626A-4, and the 89626A-4 DASH. Each game's B-board holds its program, graphics and sample ROMs and the PAL devices that map them, and the CPS-B sits on a C-board between the two, except on Forgotten Worlds and Ghouls'n Ghosts, where it is on the B-board itself.
The main processor is a Motorola 68000 at 10 MHz, or 12 MHz on the later boards, running from its own oscillator apart from the 16 MHz video clock, with one wait state on every bus cycle. Sound is handled by a Zilog Z80 at 3.579545 MHz, which takes commands from the main processor through two latches. The audio is generated by a YM2151 (OPM) at 3.579545 MHz feeding a YM3012 DAC and an OKI MSM6295 ADPCM sampler at 1 MHz, mixed through the board's output stage and an HA13001 power amplifier. Audio output is mono.
Every clock on the A-board descends from three oscillators: the 16 MHz video clock, halved to 8 MHz for the pixels and divided down to 1 MHz for the MSM6295, the 68000's own 10 or 12 MHz oscillator, and a 3.579545 MHz oscillator for the Z80 and the YM2151.
The video system outputs 384x224 in a horizontal orientation, with Mercs, Varth and 1941 having the monitor installed vertically. There is no CRTC on this PCB; the CPS-B generates the raster from its own counters, giving an 8 MHz pixel clock with an HTOTAL of 512 and a VTOTAL of 262. Each 64.00 µs line splits into 384 active pixels (48.00 µs), a 32 pixel front porch (4.00 µs), a 36 pixel sync (4.50 µs) and a 60 pixel back porch (7.50 µs) for a 15.625 kHz horizontal rate, while each 16.77 ms frame splits into 224 active lines (14.34 ms), a 12 line front porch (0.77 ms), a 3 line sync (0.19 ms) and a 23 line back porch (1.47 ms) for a 59.637 Hz vertical rate. On the later B-boards, the 91634B-2 among them, a small circuit shortens the composite sync to 28.5 pixels (3.56 µs), as measured on the PCB.
Graphics are made up of three scroll layers, sprites and two star layers, all at 4bpp. Scroll 1 uses 8x8 tiles, scroll 2 uses 16x16 tiles with optional per-line row scroll, and scroll 3 uses 32x32 tiles, while sprites are 16x16 blocks that combine into larger objects. The CPS-A takes the 68000's bus on every line to read the sprite list, the tile maps, the row scroll and the palette from graphics RAM, draws the sprites into one bank of a double-buffered frame buffer built from HM53461 video RAMs while the other bank is on display, and addresses the graphics ROMs. The CPS-B shifts the graphics data out, mixes the layers under each game's priority masks and drives the palette RAM. It also carries a multiplier, raster counters and the game's configuration, fixed inside the earlier CPS-B parts and loaded into the CPS-B-21 from its default mode or a battery-backed key.
The palette is RAM rather than PROM, 4,096 entries of 16 bits filled from graphics RAM by the CPS-A's palette copy. Each entry holds four bits each of red, green and blue and a four-bit brightness, converted by resistor networks whose values were measured on the board. That gives 4,096 entries in 12-bit RGB, each at one of 16 brightness levels.
Development Challenges:
Capcom ASICs:
Loic Petit (WydD) did the majority of the work on both Capcom ASICs. He traced the CPS-A and the CPS-B from their die photographs, cell by cell and sheet by sheet, and without his traces none of this would exist. Both are CMOS cell-based designs, and retracing them with the model turned up the faults that kept them from running.
The CPS-A (DL-0311) is the video controller. It holds the video counters, the bus requests and the task sequence that takes the 68000's bus on every line, the palette copy, the graphics ROM write and address output, the sprite list fetch and the double-buffered sprite frame buffer, and the scroll fetch, scroll positions and star addresses. Retracing it, I corrected a bus request clock pin wired to the reset rail, scroll decoders whose spare inputs were tied low so they never fired, scroll drivers enabled at the wrong time and fighting the sprite driver, video RAM timing inverters wired in reverse order, a sprite address gate that read sprite entries from the wrong area, the frame buffer's X and Y write buses crossed, a palette bus run to the wrong bus, a frame buffer counter clocked on the wrong phase, and the scroll pads in reversed order. The remaining faults were gates whose type or wiring only the die could settle, among them ORs that are NORs, a toggle clocked from the wrong phase and swapped inputs on complex gates. Below are the CPS-A die's block floorplan, its extracted layers and its circuitry by block:
The CPS-B (DL-0921) is the video mixer. It generates the video timing and sync, shifts out the three scroll layers, the sprites and the two star layers, mixes them under the priority masks, addresses the palette, and carries the raster counters, the multiplier, the security check, the CPS-ID and the configuration key. Retracing it, I corrected a debug bus drawn in place of the test data bus, duplicate address labels shorting address bits together, the palette copy pads, six layer-order flip-flops with their clock and clear swapped, graphics load strobes on the wrong half of the clock, scroll 1 and scroll 3 outputs latched on the wrong strobes, swapped fine-scroll delay paths, a scroll 3 counter loading six pixels late, the key registry's address order, the bit order into the shift registers, and the clock of the blanking and sync registers. I also added a cell the trace was missing, without which the scroll 2 palette never updated. Below are the CPS-B die's block floorplan, its extracted layers and its circuitry by block:
The first frames out of the traces were a black screen with a few blocks in two or three colors. Below is Street Fighter II': Hyper Fighting as the traces first ran from extracted netlists generated from WydD's repository and as it runs now after the corrections listed:
Between those two frames sat the corrections themselves, and the images below are the same frame in gate-level simulation as each one went in. The sprites came together first, once the frame buffer's write buses, counters and video RAM timing were right, followed by the text layer and the life bars in the HUD, then the layer order. The two background layers came last, starting as stripes and scrambled rows until their load strobes, fine-scroll paths and the missing scroll 2 cell were corrected, at which point the frame matched the board.
The chip logic in the cores is netlist-driven Verilog, written from the corrected netlists in a functional form built for the MiSTerFPGA and Analogue Pocket platforms. Every register runs on the system clock with enables in place of the chips' own clocks, and the results match the gate-level netlists identically. The gate-level netlists are Verilog as well, and they can and will be used to create replacement ASICs for the CPS-A and the CPS-B.
Palette Copy and the CPU:
Writing the CPS-A's palette base register starts a palette copy, but the CPS-A only copies inside the vertical blank, on lines -3 through 15 and from line 240 on. From that write until the copy ends, the CPS-B shuts the 68000 out completely. Register writes are lost, and reads return 0xFFFF from the bus pull-ups. On the board this never shows. The vertical blank interrupt always writes the palette base inside the window, and the copy finishes long before the game touches the CPS-B again. The games depend on that timing without knowing it. Many of them use the CPS-B's multiplier for table lookups, and a multiplier read that lands inside the lock-out hands the program 0xFFFF, which becomes an address error.
Captain Commando showed the issue first. Its boot runs for nearly three seconds with interrupts masked, and the first interrupt it takes lands on whatever line the boot happens to end. On the board every 68000 cycle takes the same time, and the processor and the video start together at reset, so the boot ends on the same line at every power-up, just outside the band where the lock-out bites. With memory latency that changed from boot to boot, the boot could end anywhere, and whenever it ended inside that band the game crashed. Below is the address error it threw, recreated by forcing that one multiplier read to 0xFFFF:
The fix is based on the DL-0921 die. The lock-out is a NOR and an OR gate on the die that hold the 68000 off from the palette base write until the copy ends, and reading them gave the exact band of unsafe lines. A palette base write from about line 16 to line 93 leaves the multiplier read, about 147 lines later, inside the lock-out, which is about a third of the frame. The cores now run every 68000 bus cycle at the board's own timing, four clocks and one wait, reading the program and graphics RAM in fixed time through a custom SDRAM controller covered in the next section, so every boot ends on the board's line and never inside the band.
The core's pause function works the same way. Holding the 68000 for the pause leaves the vertical blank interrupt pending, and releasing it mid-frame would run the interrupt, and its palette write, outside the copy window. The cores release the processors at the start of vertical blank, so the interrupt runs exactly where the board would run it.
Capcom CPS-1 SDRAM Controller:
The CPS-A and the CPS-B in the cores are exact to the clock, and like the real chips they read memory at fixed points of the CPS-A's 4 MHz bus cycle and never wait. On the board every one of those reads finishes in fixed time. The graphics ROMs are mask ROMs that answer within 180 ns, the graphics RAM is static RAM that answers within 100 ns, and every 68000 cycle is four clocks and one wait. In the cores the 6 MB of graphics ROM and the 192 KB of graphics RAM live in SDRAM, so the SDRAM has to hand over every word inside the same window, every cycle. A word that arrives late isn't waited for, and the chip takes whatever is on its bus.
The K3 framework's shared SDRAM controller is built to serve every core on the framework, arbitrating between requests so each one is answered as soon as it can be. The CPS-A and the CPS-B need every word at the same point of every cycle instead, and the shared controller would require modification to suit that purpose. Rather than change a design the other cores depend on, I opted to create a memory controller specifically designed around the CPS-1 hardware.
It runs a fixed sequence of SDRAM commands over the 24 phases of the CPS-A's bus cycle, locked to the CPS-A's own graphics ROM address changes, and gives every access its own slot. The graphics ROM, the 68000 program and the graphics RAM each sit in their own SDRAM bank, and refresh has its own phase, so it never meets a read. When the CPS-A starts or restarts mid-cycle, the controller realigns to it and serves that fetch in a late slot. Graphics ROM reads now land in the same place every cycle and never miss the CPS-B's window, and frame simulation matches the gate-level frame pixel for pixel. The 68000 reads its program and the graphics RAM through the same schedule, so every one of its bus cycles is the board's one-wait cycle, 350 ns at 10 MHz and 291.6 ns at 12 MHz, on every boot.
CPS-A DMA Timing:
The CPS-A has no path of its own to the graphics RAM. To read the palette, the sprite table, the scroll tiles and the row scroll, it asks the 68000 for the bus, takes it, reads, and hands it back, and the 68000 sits stopped for as long as the CPS-A holds it. In a typical frame that happens about 245 times, so the DMA decides how much processor time a game gets in each frame.
To measure it for my initial release, I used grego's SF2 DMA test, a patch of Street Fighter II: The World Warrior that counts how many passes of a tight loop the 68000 completes in a frame between the CPS-A's bus grants. More DMA, or slower bus cycles, gives a lower count. The reference board, a CAPCOM 89626A-4 DASH running the Darksoft CPS1 Multi with a 10 / 12 MHz switch mod, averages 2C00 at 10 MHz and 3570 at 12 MHz.
That count is an average, not a fixed number. On the A-board the 68000 runs from its own oscillator, apart from the video's 16 MHz, and two oscillators are never in exact ratio, so the 68000's clock slides against the video continuously. What a bus grant costs the 68000 depends on where its clock edges fall against the CPS-A's, so every frame lands at a different point and reads a different count. This is how every CPS-1 board runs, not a fault in its parts. Below is the 89626A-4 DASH with its two oscillators, the 16 MHz video oscillator at 2F and the 68000's at 7F:
A one-minute recording of the board at 12 MHz shows it frame by frame, with a new count on nearly every frame between 356E and 3574, averaging 3570, and consecutive frames alternating high and low. A core that ties the 68000 to the video reads the same count on every frame. Below is line 1 of the board's count across 40 consecutive frames:
The cores now read the board's counts at both clocks. At 12 MHz the count changes from frame to frame across the board's 356E to 3574 spread, with the same 3570 average and the same alternating pattern as the recording, and at 10 MHz it moves around the board's 2C00 the same way. Every load runs the same sequence of counts, and every core runs it at its own 68000 clock, verified in simulation and on both platforms. Below is the same line from the core in simulation, then 40 consecutive frames from the board and from the core:
The SF2 DMA test gives one number per frame. For the next release I am writing a CPS-1 timing test ROM suite that prints repeatable measurements on screen, running on the board from the Darksoft CPS1 Multi or from our own custom flash ROMs programmed with a TL866, and the same ROMs run on the cores, where every number has to match.
Beyond the DMA, it measures the frame and raster interrupt timing, the cost of each kind of bus access during active display and vertical blank, the point where sprite, scroll and palette writes take effect, 68000 instruction timing, the CPS-B's multiplier and open bus reads, and the sound side, from the YM2151 timers and busy flags to the MSM6295 and the sound latch. A set of visual patterns with frame counters covers sprite lag, sprites per line, layer priority and row scroll, so captures of the board and the cores can be compared frame by frame.
This gives end users who like to compare against hardware the same tests and the same method we use, and they'll be able to run the ROMs on their own Darksoft Multi or program standard EPROMs for their own PCBs, with no custom hardware needed. It leaves no room for speculation, and it replaces the unfounded latency tests and the "jump" method commonly used to measure CPS hardware.
Sound:
The sound section is the Z80, the YM2151 with its YM3012 DAC, and the MSM6295, as on the board. The YM2151 in the cores is Raki's die-based IKAOPM, the Z80 is my own die-based core, and the MSM6295 is my updated version of Pramod's, built from OKI's documentation and clocked as the board clocks it, from the CPS-A's 4 MHz divided by four, with the Z80's pin 7 latch selecting its sample rate.
What leaves the chips is only half of the sound. On the A-board the YM3012's two channels and the MSM6295's output pass through an analog stage before the power amplifier. The MSM6295's output, the VOICE leg on the schematic, goes through a three-pole low-pass filter built around an op-amp, and every leg passes through coupling capacitors on its way into and out of the summing amplifier, where the FM channels enter through 56K and VOICE through 15K. That stage changed between A-board revisions. On the 89626A the VOICE filter rolls off at about 4.1 kHz, while on the original 88617A it rolls off at about 720 Hz and VOICE enters through 10K, so the samples come out duller and louder in the mix on the earlier boards.
I modeled both stages from the component values on the published schematics and on my own extracted ones, running at 192 kHz. I don't have an 88617A PCB, so a supporter verified that revision on their board. The Audio Filter option selects between the two, and each core defaults to the A-board its set shipped on, the 88617A for the earlier games and the 89626A for the later ones. The filter can also be turned off for the chips' raw output.
On MiSTerFPGA, the framework runs every core's audio through its own low-pass filter, which on top of the board modeling would filter the sound a second time. The CPS-1 cores bypass it, so both platforms run the same audio chain, and in its place the cores end the chain with their own anti-alias filter, flat across the audible band, that keeps the YM2151's high frequencies from folding back as aliasing.
Development Challenges Continuation:
There is a lot more behind this release than one post can hold. The next post picks up where this one leaves off, covering the remaining sections, MDFourier testing of the audio against boards, and the test ROM suite, along with the rest of the work that didn't fit here.
Core Options:
The MiSTer cores include video settings for aspect ratio, vertical scaling, scandoubler effects, and H/V positioning and sync adjustments, with screen rotation on Mercs, Varth and 1941. Audio settings provide separate OPM and MSM6295 toggles, each with its own volume control, and the Audio Filter selector covered above. Game settings include player mapping and per-player auto-fire at four rates, and arcade dip switches are directly accessible from the OSD.
Forgotten Worlds was built for a rotary control that turns the soldier's aim, read on the B-board through a uPD4701 counter, one axis per player. In the cores the Rotate Left and Rotate Right buttons drive that counter's inputs directly, as the control's own encoder would, and the Rotate Control option sets how they turn. Step moves one of the game's 32 aim directions per press, Continuous turns smoothly while a button is held, a full turn in 128 frames, and Step + Repeat steps once per press and repeats while held.
Every cheat in this release is custom. Rather than loading a cheat file, each core carries its own cheat module, written for that game from its program's disassembly and worked out for every set it supports. Once a frame, on the vertical blank, the module writes the game's own work RAM through a second port, and where a cheat needs it, it patches the program as it is read instead. The item and weapon selects keep the player's own values while they are off and write them back when they are turned off, so switching one off hands back what the player was carrying. Each game has its own list, from invincibility, infinite energy, lives, time and credits to stage, round and mission selects, weapon and item selects, and Dizzy Status and Easy Specials on the Street Fighter II games, and where the commonly circulated cheats stopped a game from continuing, these don't.
The Pocket cores carry auto-fire on either button or both at four rates on every game but the Street Fighter II and quiz titles, the Forgotten Worlds rotate control, a subset of the cheats and the arcade dip switches. They have no audio settings and play through the board filter of the set's A-board.
The cores support 138 sets across the 27 games, including the regional releases and revisions.
History of the Hardware and Select Games:
Capcom introduced the CP System in 1988 with Forgotten Worlds, released in Japan as Lost Worlds. The idea was one platform for many games. The A-board, with the processors, the sound and the video controller, stayed in the cabinet, and each new game arrived on its own B-board of ROMs and PALs, cutting the cost of new hardware for operators. Capcom took an old game back at a fixed price toward a new one, or changed the software on a board sent to its service department.
After Forgotten Worlds and Ghouls'n Ghosts, the CPS-B moved off the B-board onto its own C-board. Each game's CPS-B carries that game's own configuration, its layer control and priority registers, its multiplier and its ID, so a B-board only runs with its matching CPS-B and a board couldn't be converted to another game by swapping ROMs. The later CPS-B-21 could take its configuration from a key held by a battery, and a board whose battery runs flat loses the key and, with it, the game.
The early CP System games came out of a small group around Yoshiki Okamoto, then at the center of Capcom's development, and the staff signed their work with nicknames. Lost Worlds was the first game for Akira Nishitani (NIN NIN), Capcom's first dedicated planner, who designed it alongside Akira Yasuda (AKIMAN), Noritaka Funamizu (POO) and Okamoto himself (MR. KIHAJI), with music by Tamayo Kawamoto and Yoshihiro Sakaguchi. It started out as an action game rather than a shooter, and its homing laser was Nishitani's idea.
Ghouls'n Ghosts, released in December 1988, is the sequel to Ghosts'n Goblins and was designed by Tokuro Fujiwara, the series' creator, with music by Tamayo Kawamoto.
Final Fight began as a Street Fighter sequel and was shown at trade shows as Street Fighter '89 before taking its own name for its 1989 release. Okamoto produced it, with Nishitani and Akiman as its planners. Lost Worlds had not been a hit, so the team was cut down and given less memory than Lost Worlds had, and Final Fight became a hit regardless.
Street Fighter II: The World Warrior came in 1991 from a new team that split off from Okamoto's after Final Fight, to make a follow-up to a Street Fighter that was still being played head-to-head overseas. Nishitani directed, Akiman designed alongside him, Okamoto produced, and Yoko Shimomura (SHIMO-P) wrote almost all of the stage music with Isao Abe. Champion Edition and Hyper Fighting followed in 1992 on the same hardware.
Nemo is the one we wanted to spend a little more time on. Little Nemo began as an American newspaper comic, Winsor McCay's Little Nemo in Slumberland, a full-page color Sunday strip that debuted in The New York Herald on October 15, 1905, in which a young boy dreams his way through Slumberland and wakes up in the last panel every week. Japan took it in as its own!
A Japanese translation, Yume no Kuni no Little Nemo, was published in 1976, and Yutaka Fujioka, the founder of Tokyo Movie Shinsha, secured the film rights from the McCay family and put fifteen years and a reported 5.5 billion yen into a full-animation feature made for American audiences. Hayao Miyazaki and Isao Takahata both worked on it before leaving the project, Moebius shared the story credit, Chris Columbus and Richard Outten wrote the screenplay, the Sherman Brothers wrote the songs, and Disney animators Frank Thomas and Ollie Johnston advised. Little Nemo: Adventures in Slumberland was released in Japan in July 1989 and in the United States in 1992.
Capcom adapted the film twice in 1990, as Pajama Hero Nemo on the Famicom, released in the West as Little Nemo: The Dream Master, and as this arcade game, made by a different team at the end of the year. Okamoto directed, Funamizu (POO) planned it and supported the characters, Yukio Arai (CBX) led the programming with Kazuo Yamawaki (WAKIO), Mizuho Kageyama worked on the objects, and Yoko Shimomura (SHIMOPII) composed the music, months before Street Fighter II.
Player one is Nemo with King Morpheus's scepter and player two is Flip with his cane, through seven stages to rescue Morpheus and Princess Camille from the Nightmare King. Enemies fall to the scepter, to thrown objects or to a stomp, quick chains of hits raise the score, and the yashichi, Capcom's recurring pinwheel, turns the player red for a stronger super attack, with nods to other Capcom games along the way. The earliest program is the World version dated November 9, 1990, followed by the Japanese version of November 20 and a World revision of November 30, and the Japanese program shipped on two different B-boards, the older 88622B-3 and the 89625B-1. The cores support all four sets. Reviewers at the time praised its graphics and compared it to Ghouls'n Ghosts, though Computer and Video Games found it too easy. It was shown in the UK at the ATEI show in 1991 and previewed for the CPS Changer, but the home version never came out, and the arcade game has never been re-released.
From 1992 Capcom also built the CP System Dash, the QSound boards behind games like Cadillacs and Dinosaurs and The Punisher, and in 1994 it brought the system home in Japan as the CPS Changer, sold by mail order. Both are platforms of their own and are not part of this release. The CP System II followed in 1993, and the last CP System games, Pnickies, Quiz Tonosama no Yabou 2, Pang! 3 and Mega Man: The Power Battle, came in 1994 and 1995. Production ended in 1995, and Capcom ended repair support for the system on March 31, 2015.
Halloween Releases:
For Halloween, Coin-Op Game Studio, the side project Pramod has spent the last six months on, has finally released two arrangements. Both are out for the Nintendo 64 and the PS Vita, and each is built from your own copy of the arcade ROMs by a kit that holds no game data of its own.
Batrider: Chase! arranges Raizing's 1998 Armed Police Batrider with a new CHASE! mode, built around a chain to build, medals that fly to you, the Chase Break and a rank that stays within reach. The original Armed Police Batrider sits on the same title screen, and each keeps its own high scores. It is available on GitHub - https://github.com/psomashekar/batrider-chase-release
Guwange: Omen arranges Cave's 1999 Guwange with a designed crimson palette, reworked skull-meter rules with the OMEN X2 mode, and a hitbox marker. The console versions run the arcade program itself, translated for the console, on a model of the arcade board, with the original Guwange, the Special (Blue Label) version and Omen all included. The kit also builds Omen for the arcade, as four patched ROMs for MAME or for a real Guwange Blue Label board. It is available on GitHub - https://github.com/psomashekar/guwange-omen-release
Both N64 versions run from a flash cart with the Expansion Pak, the Vita versions install through VitaShell, and each repository carries instruction booklets, a cartridge label and box art for making a physical N64 copy.
Updates:
Follow-up posts on the CP System will be coming shortly. Toaplan, Raizing and Cave have received the same treatment, with their chips rebuilt from available dies and netlists, and that is why those releases have taken as long as they have.
Moving on to the Analogue Pocket, the issue that kept pupdate from downloading Bubble Bobble and The Lost Castle in Darkmist is fixed, and Pramod's original Midway beta cores now use a legacy key included with the release. Both are pushed to the Distribution-OpenFPGA repository and are available through pupdate.
I apologize for the delay on both, and thank you for your patience. The files for today's release are carried by update_all on MiSTerFPGA and by pupdate on the Analogue Pocket. Please allow the updaters time to sync before pulling them down. They are also available here.
Comments (10)
It took, what, 38 years for someone to get the sound right? Very well done on that previously insurmountable accomplishment and everything else you've worked on here with great attention to detail. The accuracy involved is astounding, and what a wonderful surprise today! I just told someone this is the best news I've ever gotten in my entire life. Ha! Will MK be benefitting from this new MSM work as well? I did see the blurb on upcoming Midway updates, so I would be excited for that, for sure.
Thanks! Everything that uses the MSM6295 will benefit from the work done here. It's not just the OKI, it's the actual PCB filtering. I've been doing expansion on modules and framework the last few months and rolling things out slowly over the last few releases.
Hi! The core runs great. Will arcade SNAC support be added in a future update, similar to how Jotego did it for his CPS1 core? Also, when using video mode 12 (1920x1440), the screen displays very small Is there a way to fix the scaling for this mode
No plans to support user I/O at the moment. I cannot replicate that issue, support is handled in discord. Glad you're enjoying it.
Love to see different approaches. Thanks team!
Outstanding, thank you all for your hard work and dedication to preservation and accuracy.
Is a release of a Guwange Omen MRA is in the books ?
Epic update and incredible effort to really dial in hardware accuracy. Thanks for your hard work!
Credits/Acknowledgements - Look at that lineup! Other CPS1 Core: How do I build an FPGA implementation that behaves like a CPS-1 arcade board? Coin-Op Collection Core: What exactly did Capcom build inside each chip, and how can I reproduce that circuitry in an FPGA? Silicon level preservation.
the REAL CPS1!
