Coin-Op Collection Presents: The Lost Castle in Darkmist (Seibu SEI-8608)

Today's beta release for the Analogue Pocket and MiSTerFPGA platforms is The Lost Castle in Darkmist, a 1986 Seibu Kaihatsu arcade game built on the SEI-8608 hardware. It is a vertically scrolling action game where a warrior in golden armor fights through the demons of the Lost Castle of Darkmist with a sword and magic.

The game was developed by Seibu Kaihatsu and distributed by Taito. The hardware is split across two boards. The SEI-8608-A main board carries a Z80, three tile layers, the sprites and the PROMs, while the SEI8608B sound board carries a Toshiba T5182 and a YM2151.

This post covers a technical overview of The Lost Castle in Darkmist, the work the board required, and the game itself. Below is footage taken from my PCB:

Licensing:

The Lost Castle in Darkmist is 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 core. 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 core is 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.

Overview:

The Lost Castle in Darkmist runs on Seibu Kaihatsu's SEI-8608 hardware (main board SEI-8608-A / M6100213A, sound board SEI8608B), driven by a Z80 at 4 MHz running an encrypted program from a fixed window at the bottom of the map, with a banked window above it paged over two banks.

Sound is handled by a Toshiba T5182 at 3.579545 MHz, a custom package holding a Z80 die with its own mask ROM and RAM. It takes commands from the main processor through a shared RAM guarded by semaphore flags, and it also reads the coin switches. The audio is generated by a YM2151 at 3.579545 MHz feeding a YM3012 DAC, through Seibu's HB-4 custom audio package and a Sanyo LA4460 power amplifier. Audio output is mono.

Every clock on the main board descends from a 12 MHz crystal, halved to 6 MHz for the pixel clock and divided by three to 4 MHz for the Z80, while the sound board carries its own 14.31818 MHz crystal, divided by four to 3.579545 MHz for both the T5182 and the YM2151.

The video system outputs 256x224 in a vertical orientation. There is no CRTC on this PCB; the raster comes out of the counter chain and a timing PROM, giving a 6 MHz pixel clock with an HTOTAL of 384 and a VTOTAL of 262. Each 64.00 µs line splits into 256 active pixels (42.67 µs), a 43 pixel front porch (7.17 µs), a 29 pixel sync (4.83 µs) and a 56 pixel back porch (9.33 µs) for a 15.625 kHz horizontal rate, while each 16.77 ms frame splits into 224 active lines (14.34 ms), a 16 line front porch (1.02 ms), a 4 line sync (0.26 ms) and an 18 line back porch (1.15 ms) for a 59.637 Hz vertical rate. These timings are taken from the PCB.

Graphics are made up of three tile layers and sprites, all at 4bpp. The text layer is a 32x32 map of 8x8 tiles in video RAM, while the background and foreground are built from 16x16 tiles whose maps are read straight from ROM, 512x64 and 64x256 tiles in size, and both scroll. Up to 128 16x16 sprites sit in their own RAM. Each layer has its own color PROM, which decides which pixel values are transparent and picks an entry from that layer's 64-entry bank of the palette. Two more PROMs handle the raster; the 63S281 at L1 sets the vertical timing and places both interrupts, and the 82S129 at D11 drives the sprite shift registers.

The palette is RAM rather than PROM, 256 entries of 12 bits across two RAMs, four bits per gun, converted by Seibu's HB-5 custom package, a resistor ladder that weights each bit. That gives 256 entries in 12-bit RGB.

Development Challenges:

Main CPU and Interrupts:

The main program is encrypted. An opcode fetch and a data read of the same address decrypt differently, so the two views of the program ROM disagree at nearly half of its addresses, while the second program ROM is plain and banked by bit 7 of the control latch at C804. There is no watchdog and no NMI. The game runs from two interrupts. RST 08 runs the entire game frame, and RST 10 uploads the palette, the scroll registers and the sprite bank from shadow copies the frame code leaves behind, both with interrupts disabled.

Both interrupts come from the 63S281 at L1. Addressed by the line counter, it raises a one-line strobe at lines 28 and 240, and two of its bits supply the instruction the Z80 reads during the acknowledge: RST 08 if the acknowledge lands on lines 28 through 239, and RST 10 if it lands on lines 240 through 27. That gives the frame code 212 lines, 13.57 ms, before the upload runs, and the upload 50 lines before the next frame's code starts. If a busy frame runs past line 27 of the next frame, the pending interrupt is acknowledged as RST 08 and that frame's upload is skipped. Emulation never reads the L1 PROM. It raises RST 08 at line 0 and RST 10 at line 240 of a 256-line, 60 Hz frame, giving the frame code 240 lines and the upload 16, and it fixes the instruction when the line is raised rather than when it is acknowledged. The core reads the PROM on every line and builds the instruction from the line the acknowledge lands on, the way the board does.

The processor underneath it is xZ80, our own Z80, and this is its first release. It is a fully synchronous, cycle-accurate Verilog implementation, every state change landing on the clock edge under a clock enable. Every one of the 1,792 opcode slots across the seven decode pages executes as the silicon does, documented and undocumented, machine cycle by machine cycle and T-state by T-state. That includes the internal registers whose effects show in the undocumented flag bits, all three interrupt modes with mode 0 executing whatever instruction the board supplies, NMI, HALT, WAIT, bus requests and refresh. Where Zilog's documents are silent, its behavior was settled against a transistor-level simulation of the NMOS Z80. A test bench of 3,729 self-checking tests passes in full. It also runs inside x5182, our T5182, covered below.

Video Timing:

The 63S281 at L1 is a vertical timing PROM, addressed by the line counter. Its outputs give the display enable for lines 16 through 239, the vertical blank, a render window one line ahead of the beam for the tile layers, a sprite scan window two to three lines ahead, and the interrupt strobe and instruction bits covered above. The PROM has 256 addresses for a 262-line frame, so six addresses are read twice, and every one of them holds the blanking word. Vertical sync is not in the PROM; it comes from the counter, four lines starting at line 256.

That frame is 384 by 262 at 6 MHz, 59.637 Hz, which is what the board measures. Emulation runs a 256-line frame at 60 Hz and hands the display a finished frame with no sync at all. The game logic runs once per frame, so it plays about 0.6 percent faster than the board. The core runs the board's 262-line frame and drives sync where the board does, so the game runs at the board's speed.

The board draws each line as the beam reaches it, so everything on screen is taken from the state of the hardware at that line. The core renders the same way, reading the scroll registers, the layer enables and sprite RAM on each line inside the windows L1 sets. Emulation draws the whole frame once, from the state at the end of the picture, so a change the game makes partway through the frame, such as switching a layer on or off, lands on the whole frame rather than splitting it at the line where it happened.

Graphics Pipeline:

Each layer's color PROM is addressed by the tile's color and its pixel value, and its output either marks the pixel transparent or picks one of the layer's 64 palette entries. Transparency is decided per color rather than by one fixed pixel value, so on the foreground a pixel value of 0 is see-through in some colors and solid in others. The layers stack in a fixed order, text over sprites over foreground over background.

The sprite pixels come out of shift registers driven by the 82S129 at D11. Addressed by the dot count, it loads a new pattern word on the first dot of every group of four, shifts on the next three, and holds the registers still outside the sixteen dots of a sprite row. Emulation loads the D11 PROM as unknown and never uses it, decoding each sprite straight from ROM into a frame buffer. The core serializes every sprite through the shift registers under the PROM's control, the way the board does.

The sprite color PROM is where the board and emulation part ways on screen. On the board, bits 4 and 3 of a sprite's color reach the sprite color PROM swapped, which trades color groups 4 through 7 with 8 through B. Emulation takes the bits straight, so the water a player wades through is drawn as a light gray box and the brown enemies come out pink and red. Its driver carries a note about the water, asking whether it is a fault of the board itself. It is not: on the PCB the water stays blue with a darker ripple, and the value the note expects, 0x0C in place of 0x14, is those two bits swapped. The core swaps the two bits into the sprite color PROM as the board does, so the water and the enemies come out in the board's colors. Below is a comparison of the sprite colors between emulation and the core:

Each gun of Seibu's HB-5 is a ladder of 2.2K, 1K, 470 and 220 resistors, one per bit, which is close to binary but not exact, so its sixteen levels are not evenly spaced. Emulation spreads the sixteen levels evenly from black to full. The core uses the ladder's own weights, so the low levels come out darker and the high levels brighter than in emulation, with the largest jump between levels 7 and 8, and the background's earth tones sit darker as they do on the board. Below is a comparison of the palette between emulation and the core:

In a cocktail cabinet the game sets bit 3 of the control latch on player 2's turn, and the board turns the picture around for the opposite seat. The game also sets an extra bit on sprites at the right edge on that turn, which emulation reads as a random palette. Emulation has no cocktail support. The core flips the screen just like the PCB at the start of the frame when the game sets the bit, and draws in reverse correctly.

Sound:

The T5182 is a Toshiba custom package. It contains a Z80 die, its own mask ROM holding the sound driver, a small RAM, and the decoders that map memory and I/O onto its pins. The music and effect data sit in an external ROM whose data lines are crossed on the board, three pairs swapped, and the driver's own checksum of that ROM only comes out right with the swap in place. The main processor talks to it through a shared RAM holding a command queue and an answer queue, guarded by a pair of semaphore flags, one for each side. It raises the T5182's interrupt by writing a single register, and the YM2151 raises the other. Below is the T5182 driving the YM2151 and its DAC, from schematic extraction:

The coin switches are wired to the T5182, not the main processor. The driver samples them on every overflow of the YM2151's timer B, about 94.5 times a second, and debounces them itself. A press from about 21 ms up to half a second counts as a coin, but holding the switch closed for half a second or longer is reported as a jam, and the main program prints COIN ERROR!! and stops with interrupts off until the board is reset. Emulation turns every coin press into a two-frame pulse, so a coin can never jam. The core passes the switch to the T5182 for as long as it is held, so a coin credits and jams the way it does on the board. Below is an example:

The package underneath it is x5182, our own T5182, built on xZ80 and also in its first release. It carries the package's memory and I/O decode onto its enable pins, the internal mask ROM and RAM, and the data bus as the package drives it, and a test bench of 97 self-checking tests passes in full on top of xZ80's own.

The YM2151 shifts both of its channels out serially to the YM3012 DAC. Every instrument in the driver's table enables both channels, and the board adds the two together, so the output is mono. Each held channel passes through a 20K resistor into Seibu's HB-4, where two followers and an inverting summer add them at unity gain, then through the volume preset into the Sanyo LA4460 bridge amplifier. The YM3012's hold capacitors share their charge with the HB-4's input capacitors after every sample, which rolls the top end off from about 5 kHz, and the LA4460's feedback capacitors take out the bass below about 64 Hz. Emulation sends the YM2151 straight to the speaker and models none of that chain. The core runs the board's chain stage by stage off the schematic, so the PCB filter setting is about 3 dB down at 64 Hz and 5 kHz, 6.8 dB down at 10 kHz and 12.5 dB down at 20 kHz, as the schematic's values call for. Below are the HB-4 and the output amplifier, from schematic extraction, along with audio playback without and with the HB-4 filter:

Core Options:

The MiSTer core includes video settings for screen rotation, aspect ratio, vertical scaling and cropping, scandoubler effects, and H/V positioning and sync adjustments. The Lost Castle in Darkmist runs vertically, so a screen rotation toggle is included for HDMI displays, and a screen flip turns the picture around for monitors mounted clockwise, so the monitor doesn't need to be rotated.

Audio settings provide an OPM toggle with its own volume control at 100, 125, 150 or 175 percent, and a filter selector that switches the board's own output chain in or out. Arcade dip switches are directly accessible from the OSD, and the Extend switch is labeled from the game's own table, where emulation mislabels three of its four settings and its default. Game settings include per-player auto-fire on either button or both with adjustable rates, mapping options for Player 1 and Player 2, and a synced mapping mode that mirrors Player 1's layout to Player 2.

Cheats are accessible from the OSD and cover infinite credits, time, lives and energy, invincibility, magic item and extra item selects, and always having swords, a healing potion and treasures. Always Have Swords also sets the sword's power, which emulation's version of the cheat leaves unchanged, and the item selects write the whole item list pointer rather than half of it. Invincibility patches the program on the processor's read path, so the ROM itself is never changed and switching it off restores the original code at once.

The Pocket core provides auto-fire on either button or both at adjustable rates, shared by both players, and carries infinite time, invincibility, infinite lives, the magic and extra item selects, and always having swords, a healing potion and treasures. It has no audio settings and plays without the board filter. Arcade dip switches available on Pocket are Difficulty, Lives, and Extend.

History and Gameplay Information:

The Lost Castle in Darkmist was developed by Seibu Kaihatsu and distributed by Taito in Japan from January 19, 1987, as a board only at an operator price of ¥138,000, although its title screen carries a 1986 copyright. World Games brought it to the United States as a conversion kit licensed from Taito America. No staff credits were ever published and the composer is undocumented, but the game's default high score table holds ten surnames, and four of them match Seibu's Raiden credits from 1990; programmers Kondo and Mori, graphic designer Wada and hardware designer Segawa, most likely the same staff. It never reached Game Machine's top 25 table cabinet chart in the months after its release.

A warrior in golden armor sets out alone for the Lost Castle of Darkmist, where the demons conquering the world have gathered and from which no soldier has returned. The screen scrolls upward on its own, and the warrior fights with an 8-way stick and two buttons, one swinging the sword and one casting magic, and getting caught against a wall by the scroll costs a life. A power gauge drops with every hit and with every use of a weapon, and a life is lost when it runs out. Seven scenes make up the game, two to a stage, with the castle entered in the second scene of each, and the last stage is a single scene.

Defeated enemies leave treasure chests holding swords, magic jewels and items, and some of them are curses. Bigger swords raise the warrior's power, from a small sword up to a magical one. Magic jewels add fireballs, a protective barrier or a flying light, and other items freeze enemies, clear the screen, let the warrior walk on water or cut the damage taken, while the bracelet and the blue ring take away the sword or the magic and the black pitcher drains power. Treasure is traded in the town scenes at the arms shop, the pharmacy, the magic shop and the trade market. Clearing a stage pays 10,000 points with an emblem, and collecting four emblems pays a 100,000 point bonus. Continues are always on, because the dip switch that could have disabled them was patched out of the program. Overall, The Lost Castle in Darkmist is a forced-scroll action game where every swing of the sword costs power, so knowing when to fight matters as much as fighting.

The program ROM also carries a leftover from the factory. Its last section holds fragments of a Japanese EPROM programmer's menus, its device list and its write prompts, sitting in the tool's buffer when the game was burned, and an unused NO DEAD MODE label sits beside the free play message.

Updates:

The Lost Castle in Darkmist follows Bubble Bobble and KiKi KaiKai as the next Taito release, and it is the first release to ship xZ80 and x5182. We'll see an additional Taito game release later today.

The files 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. The files are attached to this post as well if you would rather install manually.