Happy New Year! Today's release for the Analogue Pocket and MiSTerFPGA platforms marks the final entry to the Twin Cobra platform, Hi Shou Zame (飛翔鮫) / Flying Shark / Sky Shark.
This is one of my favorite shooters and an arcade blockbuster that became Toaplan's biggest commercial success, introducing the hardware and sound design that would define their golden era.
This post covers a technical overview of the TP-007 (Sky Shark) hardware along with updates on other projects. The last few weeks have been hectic, and I wanted to consolidate everything into one comprehensive update.
Overview:
Sky Shark runs on Toaplan's TP-007 hardware, which later evolved into the TP-011 used by Twin Cobra. The PCB is built around a Motorola 68000 running at 7 MHz, with a TMS320C10 DSP (GCX-01 / GCX-02) handling protection and math-intensive operations.
The video system uses Toaplan's custom tilemap generators (GLX-02) for the text, background, and foreground layers, alongside a custom sprite engine (GLX-01) for object rendering. A Hitachi HD46505SP Cathode Ray Tube Controller (CRTC) is responsible for video timing and sync generation, outputting 320×240 at a 54.878 Hz refresh rate.
Sound is managed by a Zilog Z80 at 3.5 MHz paired with a Yamaha YM3812 (OPL2) for FM synthesis. Audio passes through an LM158 dual op-amp configured as a low-pass filter before reaching the amplifier, softening the raw OPL2 output for a warmer sound.
Development Challenges:
Since Sky Shark and Twin Cobra share the same platform, the core was developed alongside Twin Cobra using the TP-007 schematics as the primary reference and verified against my TP-007 PCB. The main differences between the two boards are the DSP protection variants and CPU clock speed.
The GCX-01 / GCX-02 protection DSP on TP-007 enforces strict banking. Writes only succeed when targeting banks 3, 4, or 5 (shared RAM, sprite RAM, palette RAM). Anything else is silently ignored by the GCX variant.
Twin Cobra's GCX-04 removed these restrictions entirely, which made that core simpler to bring up. Getting Sky Shark running meant validating both the bank register and address on every DSP write, plus nailing the BIO handshake timing between the 68000 and DSP. If either is off, the game hangs.
Technical Information:
The TP-007 video system splits graphics generation between two custom chip families: three GLX-02 chips for tilemaps, three GLX-01 chips for sprites. Both read attributes from dedicated RAM, fetch pixel data from graphics ROMs, and render into line buffers synchronized by the CRTC.
The GLX-02 produces three tile layers: text (TX), background (BG), and foreground (FG). Each operates on an 8×8 tile grid mapped into a 512×256 space, with per-layer scroll registers for smooth scrolling. BG and FG support banking to switch tile sets without touching VRAM. Tile attributes encode index and palette, BG and FG use 12-bit indices at 4bpp, TX uses 11-bit indices at 3bpp. BG writes every pixel as the base layer; FG and TX only write non-zero pixels for transparency.
The GLX-01 handles up to 512 sprites per frame. Each is 16×16 at 4bpp with independent positioning, flip flags, and a 6-bit palette. The hardware walks the sprite list every scanline, checks Y visibility, then fetches 8-pixel chunks for visible sprites. A 2-bit priority field controls draw order, higher priority overwrites lower at each X position.
In the FPGA core, I consolidate each chip family into a single time-multiplexed state machine rather than instantiating three copies. The tilemap module renders BG, then FG, then TX sequentially each scanline. The sprite module processes all 512 entries serially, tracking priority per X coordinate. Both use double-buffered line buffers keyed off the vertical counter's low bit. Fewer resources, same behavior.
The TMS320C10 DSP runs protection and math operations, with Toaplan marketing these as the GCX series. The 68000 triggers a DSP interrupt to issue commands, then polls the BIO pin for completion. The DSP drives BIO low when finished, clearing it after the 68000 acknowledges. The core uses Raki's IKA32010, an open-source, BSD licensed TMS320C10 implementation available on GitHub. Raki and I worked together to validate it against the TP-011 (Twin Cobra) hardware.
Core Options:
Both the MiSTer and Pocket cores are built on the k3 framework. The MiSTer core includes video settings for aspect ratio, vertical scaling and cropping, refresh rate (native 54.878 Hz or NTSC), scandoubler effects, and H/V positioning adjustments.
Audio settings provide OPL2 toggle, an optional IIR low-pass filter, and volume control. Game settings include per-player auto-fire with adjustable rates, and a cheats menu with Invincibility, Infinite Lives, Infinite Bombs, Max Power, and Rapid Fire. Arcade dip switches are directly accessible from the OSD.
The Pocket core exposes auto-fire rate selection (Faster, Fast, Medium, Slow) and cheats through the interact menu. Available cheats include Invincibility, Infinite Bombs, and Max Power.
Dip switches are fully configurable: Game Difficulty (A through D), Extend thresholds for bonus lives (50k/150k, 70k/200k, 50k only, 100k only), Fighter Counts (1, 2, 3, or 5 lives), and Service Mode for screen testing. A Dip Switch Display option shows the current switch settings on screen.
History, Gameplay, and Regional Information:
Sky Shark released in March 1987 as Toaplan's third shoot 'em up and their first on the Motorola 68000. Published by Taito in Japan, Romstar in North America, and Electrocoin in Europe, it became Toaplan's biggest arcade hit, placing second among Japan's table arcade games that year.
Development was led by Masahiro Yuge and Tatsuya Uemura, who handled planning, programming, and music, with Koetsu Iwabuchi on graphic design. The team drew inspiration from Apocalypse Now for the game's tone, and a company trip to Thailand shaped the jungle and river environments.
The game marked several firsts for Toaplan. Horizontal scrolling tied to player movement expanded the play area beyond the visible screen, letting players force enemies offscreen to reduce incoming fire. It was also the studio's first title to use FM synthesis via the YM3812, which remained their sound chip of choice through Vimana.
Gameplay builds on the shot and bomb formula from Tiger-Heli. The biplane's forward shot widens as power-ups are collected from red plane formations, maxing out at five levels. Bombs detonate in a fixed area rather than clearing the entire screen, destroying enemies and nullifying bullets caught in the blast. Each stage resets the bomb count to three, and any unused bombs convert to 3000 bonus points.
Five stages make up a full loop. After clearing the first loop, stage 1 drops out of the rotation entirely since it serves as a tutorial for new players. A dynamic rank system scales bullet speed and enemy health based on progress, power level, and loop count. The sequel Fire Shark (Same! Same! Same!) arrived in 1989.
Regional differences are minor. Japan received the game as Hi Shou Zame (飛翔鮫), Europe as Flying Shark, and North America as Sky Shark. The Japanese release runs slightly harder by default, mainly affecting how often the white 1UP plane formations appear. Bullet speed and checkpoint placement are the same across all versions. The premise is unchanged: a lone pilot called the "Flying Shark" launches a last-ditch mission as allied bases fall to enemy forces.
Updates:
Snow Bros. Nick & Tom Updates:Over the weekend, I released an update to the Snow Bros. Nick & Tom core. The YM3812 audio was pitched too high even with correct clock enable generation. PCB measurements confirmed the correct timing intervals are 96 µs and 384 µs for 3 MHz.
The core now matches hardware, while current emulation in MAME runs slightly slower than the real PCB. Below is an audio comparison demonstrating the pitch difference. Due to time constraints, I did not provide a capture of the PCB audio for comparison.
MAME .281
FPGA - 01/10/2026
Midway Z/Y/T-Unit Updates:I mentioned things have been hectic. I haven't had much free time to work on projects since the week of Christmas, but I wanted to give an update on the Midway Z/Y/T-Unit cores.
The Z/Y-Unit cores are now complete. The GPU that was omitted in the initial release has been added, and the pseudo frame-buffer has been removed. Previously, the frame-buffer was needed because the architecture couldn't keep up with real-time rendering.
Pramod tailored the architecture to the K3 framework and was able to fit the design on the Analogue Pocket. It now runs natively on the K3 memory structure without that workaround.
The ball's in my court to validate, test, and add additional features like cropping for digital displays, proper sound mixing, and variant support. This is a week or so of work in itself (25–35 hours). I'll make it a priority and publish a new beta by the end of the month.
T-Unit has been stood up, is functional in simulation, and is now synthesizable in Quartus. The next step is hardware validation. After the Midway Z/Y-Unit cores are released, the first T-Unit title, NBA Jam, will follow, and work will resume on the audio DSP for Midway's Wolf Unit.
Below is footage of Z-Unit, Y-Unit (CVSD), and Y-Unit (ADPCM) titles. These aren't production builds and may have minor glitching.
Technos16 Updates:Pramod was able to resolve the issue with slowdown not present in hardware for Double Dragon 3, The Combatribes, and WWF Wrestlefest. He took the work I did earlier this year, which improved upon the initial MiSTer release, and migrated everything to the unified K3 framework for both the Analogue Pocket and MiSTerFPGA platforms.
This work provides the unified K3 template necessary for all the Toaplan work I've been doing to sync the Pocket and MiSTer cores. The memory controllers have been updated with new additions from Midway, including an agnostic loader.
What does this mean? Custom scripts will no longer be required for Technos16, Cave68k, etc. No more transformation scripts to work around MRA limitations. Loading is now platform-agnostic in K3, giving us control over the loader and allowing for advanced graphics decoding, transformation, transposition, decryption, and deflation.
Another example of why we developed this is the Cave68k releases. Custom scripts were required due to encryption and ROM placement in DDR, and MRA parsing had an issue in mra_loader.cpp, which I noted at the time.
Rather than submit a fix, Pramod and I decided we should control how things are loaded, especially given the negative response from others who either told me I was incorrect or flat out ignored my responses. The issue was resolved a few months later when another developer ran into the same problem and had to run scripts to properly load GFX.
This is also on my to-do list. It won't require the same attention as the upcoming Midway Z/Y-Unit release but is less of a priority. Below is footage showing proper slowdown with three players in Double Dragon 3. This is not a production build and may have minor glitching.
Toaplan Twin Cobra, Wardner, Rally Bike, Snow Bros., V1, and V2 Platform Updates:Now that the unified K3 template is complete, I will begin consolidating the Twin Cobra platform, Wardner, Rally Bike, Snow Bros., and Toaplan V1. These will come with additional fixes I haven't mentioned in previous posts, based on my experiences writing new cores for KiKi KaiKai and The Legend of Kage.
This task won't take long. I already have everything in place for the Analogue Pocket and MiSTerFPGA platforms. The work I've done to get to this point was grueling, whether refactoring existing cores, rewriting them entirely, or creating new ones for additional Toaplan hardware platforms, but it makes updates like this easier to accomplish.
Mentioned above, T-Unit has been stood up, is functional in simulation, and is now synthesizable. ToaplanV2 work is in the same condition, covering both previous releases and new NEC V25 titles. Snow Bros. 2: The New Elves, Teki Paki, Whoopee!, and Truxton II are pending hardware validation, along with the first V25 entry, V-V (Grind Stormer).
Pramod has configured the GP9001 for dual usage. We'll be able to cover everything including dual GP9001 titles like Batsugun. I've started to rework Ghox, the one game that requires a Hitachi HD647180 due to its use of the external I/O. It is currently in a bootable state.
Wardner is a highly requested Toaplan title. While I have it functioning, it still needs work, and I plan to release it in late February or early March. I've also procured a Truxton II PCB so we can determine why there are ADPCM audio playback issues.
While the Raizing platform isn't a part of our Toaplan releases, it has already been updated to the unified K3 template. The core is drastically improved and will see an updated release this quarter. I don't want to go into detail at this time, but fans of this core will be pleasantly surprised.
New Projects from Taito (KiKi KaiKai and The Legend of Kage):I was getting burnt out working on Toaplan hardware in December. This happens to every developer focused on the same project for too long. I decided to look at some projects I started in mid 2025 to combat this.
I chose two titles I enjoy, KiKi KaiKai and The Legend of Kage, to help me better understand graphics decoding, peripheral integration, and what's required to write new IP in Verilog including CPUs. Both games use Motorola MCUs for protection, which meant writing new CPU cores from scratch to run authentic ROM sets.
After three months of prep work studying what was required for both games, I set them aside to focus on Toaplan. The progress I made on older Toaplan titles gave me the confidence to move forward on both projects. Both will be available as betas after the Midway release.
KiKi KaiKai uses a Motorola MC6801U4 MCU. The initial beta release will use the existing OpenCores MC6803 module, which works but has minor reset issues and is not cycle accurate.
To address this, I have written the x6801u4 from scratch in Verilog. The implementation is currently undergoing validation. Below is gameplay footage using the OpenCores MC6803 module.
The MC6801U4 is a more complex design than the MC68705P3, requiring a full peripheral wrapper with a CPU core, four parallel I/O ports, a programmable timer, and a Serial Communications Interface.
The CPU executes and runs code correctly, but I'm still debugging hit collision. Once I finish validation, a future update will replace the OpenCores module entirely and I will open source the design.
Below is gameplay footage using my x6801u4 implementation. As you can see, certain enemy objects are not recognized by projectiles. Pay attention to the pumpkins. The collision issue initially caused every sixth pumpkin to be skipped. Currently, I am debugging the collision issue in a testbench.
The Legend of Kage uses a Motorola MC68705P3 MCU for protection. Rather than rely on external assemblers or other outside sources, I wrote a complete M6805 CPU core from scratch in Verilog. Following the Von Neumann architecture model, it is designed to work as a drop-in solution for any game requiring the MC68705P3.
Below is footage from the core playing bootleg sets prior to integrating the x68705 MCU. Simulated MCU calls can boot protected ROM sets, but the game exhibits errors without a proper implementation.
The x68705 is a fully synchronous, cycle-accurate implementation covering all 62 operations (202 valid opcodes) across 10 addressing modes. There's no microcode involved, just a direct hardware state machine, matching how the original chip was designed. I referenced the MC68705P3 datasheet and M6805 User's Manual throughout development.
Below is footage from the core running protected ROM sets using the x68705 implementation. Fake MCU calls just return hardcoded values to get past protection checks. The x68705 actually runs the MCU program and communicates with the main CPU through the ports, responding dynamically like real hardware. This allows protected sets to run correctly without producing the errors seen using fake MCU calls.
The design is structured for expansion to support additional M6805 family variants like the MC68705P5, R3, and U3. I plan to open source the design and use the IP in future projects.
There are several other projects and new IP currently in development, but I don't want to announce them yet. This update provides a clear path for projects mentioned in 2025 that weren't specified by name (both KiKi KaiKai and The Legend of Kage are Taito titles), along with our remaining work.
I may release the Toaplan V1 improvements for the MiSTerFPGA platform in their current state before consolidating the cores to the unified template. If I do, they will only be available in the Discord server. Other projects may surface this quarter after completing the work discussed above.
Several new members have joined the Patreon to support the projects covered above, and we're grateful to have them. As a reminder, the Coin-Op Collection is a small team of four, and currently only two of us are actively working on these projects.
Pramod and I handle the bulk of development while balancing our personal lives and real world obligations. We also have our own responsibilities within the organization, and releases are contingent on my availability.
The majority of our work is free, we don't request or accept donations, and purchase all hardware and equipment used for development and verification. Your support here is what makes all of this possible and allows us to continue development on new and existing projects.
I've pushed today's release to their corresponding updaters. The files are also available in today's post and their respective GitHub repositories. Enjoy Sky Shark, and thank you again!
Disclaimer:All product names, trademarks, and registered trademarks mentioned are the property of their respective owners. "Analogue", "Analogue Pocket", "MiSTer", "MiSTerFPGA", "OpenFPGA", "Hitachi", "Motorola", "NEC", "Texas Instruments", "Yamaha", "Zilog", "Cave", "Midway", "Raizing", "Taito", "Technos", and "Toaplan" and all derivative works are trademarks, registered trademarks, or copyrighted materials of their respective holders. Use of these names does not imply endorsement or association with this post. All rights reserved to their respective owners. This post is for educational and research purposes only.