A ticket redemption game for kids where you have to play one or two lines of a nursery rhyme before the timer runs out.
Mariusz W. and I took an interest in this a few years back but struggled to figure out the controls and BSMT2000 interface so it remained unplayable. I revisited it this week and managed to solve these issues, partly with the help of schematics from Colorama, a redemption game which uses the same sound board.
Owing to some great work from Kale and hap, emulation of Midnight Landing had improved over time but the game could still not be classed as playable. Having recently found a video recording of the game made from actual hardware, I decided to take another look at getting it working properly.
The first difference I noticed was the lack of engine sound in MAME. I surmised that the engine sound circuit was similar to that of Top Speed; an MSM5205 ADPCM chip driven by a variable clock from a Z80 CTC. Sure enough, I was right :)
Next, I tried to figure out why the colours were incorrect. Midnight Landing's video hardware is an unusual design by Taito standards in that it is blitter based. There's 512KB of (CPU-accessible) video RAM, enough for two 520x400x8 video buffers (medium-resolution). There's also 32kx16 of palette RAM, though only 1024 entries are actually used. The raw graphics data is 4bpp and one of the blit parameters specifies a 4-bit palette value, which gives an 8-bit index into palette RAM. This only allows for 256 colours; so how is the full range of palette RAM addressed? Well, it turns out I'd overlooked the special 'clear' mode of the blitter. Video RAM regions are cleared twice; first to clear pixel data and then to set a 7/8-bit palette index for the region. This suggests there's only one 520x400x16 buffer but given that very little needs to be redrawn per frame (the instrument panel is mostly static and the background is entirely black) and most blits can likely execute within the vertical blank period, there's no need for double buffering.
The final step was to fix the analog controls. The throttle and yoke controls are read as 12-bit values, and the existing hookup appeared to have the upper nibble and lower 8-bits swapped. Once corrected, the game became playable.
UPDATE: I discovered an interesting easter egg while disassembling the game. If you get a high score ending in double digits and then enter the initials OIB, the game will then prompt you to enter your birthdate and the current date. You are then presented with your own personal biorhythm chart! Pointless eh? It's interesting from an emulation perspective at least because it's the only time the CPU writes to the framebuffer directly (other than to test the RAM).
Dell Electronics' (no affiliation with Dell Inc.) Turret Tower puts you in the seat of an anti-aircraft turret and throws fighter jets at you from all directions. The aim is simple; destroy everything. A cargo plane drops power-ups, ammo and armour replenishments to prolong your fight. The graphics are big and the sound is loud. 'Manic' pretty much sums it all up.
The main attraction of the game was its motion cabinet, which rotates the seat and monitor through 360 degrees as the joystick is moved. In its absence the game is still fairly fun to play. The hardware is an interesting fully-custom design from a time where PC-based arcade hardware was becoming prevalent. The board itself is very compact, consisting of a 25MHz MIPS R3000, a pair of Xilinx FPGAs and two 128MB SIMMs. Graphics and sound are stored on a 20GB IDE HDD (of which only ~4.5GB is used).
A DMA engine is implemented within the FPGAs which can transfer graphics data between the HDD, RAM and VRAM. Objects residing in RAM are RLE-compressed and may be down-scaled when transferred to VRAM. Additive, subtractive and multiplicative colour blending modes are supported and the hardware also implements a rudimentary hit-detection scheme.
Lastly, sound is provided by a 32-channel DMA engine mixing 16-bit samples at 44.1KHz.
Some hardware details did have me stumped for a while. Take colour blending for example. The MSB of the 16-bit source pixel data specifies framebuffer blending. The additive blending mode (used for snow, rain and bullet holes) is enabled by a video control register (of which only two bits actually have an effect) but the subtractive and multiplicative modes are selected by the state of the pixel's green and blue component LSBs! Bizarre as it seems, this hack allows sprites with different blend modes to be drawn in a single operation (such as explosions). Many sprites also have multiplicative blending enabled on their edge pixels to achieve an anti-aliasing effect. Inputs are driven by individual interrupts, which took a while to get working correctly. I've yet to figure out how the outputs for the seat motor work.
All in all, a rather interesting game to emulate!
Here is the exceedingly rare prototype arcade conversion of the infamous fighting game.
It runs on Bell-Fruit/ATD RasterSpeed hardware which features a 486SX, a TMS320C31, 4MB RAM, a Xilinx XC4010 FPGA and an NCR53C700 SCSI controller. The game is stored on a 540MB SCSI HDD.
Though 486-based the hardware bears no resemblance to PC architecture. The design is rather unusual.The video controller parses a display list where each entry specifies a horizontal pixel span. Pixels may be 8-bit palletised or 16-bit and a source address increment value can be used to perform scaling and mirroring. Pixel data is read from RAM and fed into a FIFO for video scan-out. The rationale behind this design was to avoid the VRAM bandwidth bottlenecks of traditional framebuffer and blitter designs by eliminating destination pixel writes. This does however require additional work on the CPU side to determine object visibility and to create the displays list. For scenes with many small or transparent objects this approach is rather inefficient as the resulting display list is very long. A framebuffer can however be emulated by creating a display list with a 1:1 entry for each scanline.
The DSP performs sound processing, mixing and outputs a 24KHz stereo stream. It is also used to bootstrap the 486, copying code from ROM to RAM using its internal boot loader.
As for the actual game, several improvements have been made to address some of the myriad criticisms of the home versions. For instance, any of the six robots can be controlled in both single and two-player modes. The speed has been greatly increased and it's's possible to jump over your opponent to switch sides. The attract mode is an epic Brian May fest and is by far the best part of the game. Disappointingly there's no in-game music, just some very badly looped ambient sounds.
Improvements notwithstanding, the game is still atrocious :)
Beyond MAME there are no known working instances of this game. One machine that appeared several years ago had experienced HDD failure and another recently found (from which the dump was made) has a badly corroded, non-working boardset that is unlikely to be repaired. Huge thanks should go to Ordyne for dumping his copy and ensuring this rarity wasn't lost forever.
There are at least two other RasterSpeed games, Zool and Football Crazy (a quiz game). Please get in touch if you have any information regarding them.
Here's an interesting pair which never saw life outside of the Atari labs.
The Last Starfighter is of course, Atari's aborted game adaptation of the film/game within the film. If you haven't already done so, I recommend checking-out the proposal for the game.
On show here is an unfinished cave-chase sequence. You can shoot and destroy the enemy ships in the cave but that's pretty much it (there's no end to the enemies nor the cave). A dogfight sequence was also programmed and can be seen in this game footage.
The unsightly coloured-blocks are due to missing graphics data for the text and HUD :(
Air Race is a slightly more advanced prototype where you pilot a ship around a futuristic indoor race course. Very impressive-looking stuff for 1985. Perhaps too impressive as the high cost of the hardware was the main factor that kept the games from market.
Both games ran on System IV hardware (whatever happened to System III?), comprising a 68000 and a TMS32010 DSP for geometry calculations (an extra DSP was added for Air Race). Rasterization is performed by custom hardware (Hard Drivin' and later games used a software approach).
AFAIK, the hardware for these games no longer exists. There are no ROMs - we're running the binaries that were uploaded to the RAM of the development hardware. You could go as far to say that these games are MAME-exclusives :)
I finally wrote the Am29000 CPU core needed by these games. Emulation of the math unit and 3D hardware soon followed.
The 3D performance of the system is a step above Hard Drivin' and co given that the 3D pipeline is implemented mostly in hardware. The average framerate is ~30fps as opposed to 15. Worth mentioning is the extra sound hardware that is used to generate LOUD explosions. It's like something from an analog synthesiser - there's two channels of white with pink noise passed through an SSM2047 VCF. I've included a slightly fudged but reasonable sounding simulation of it.
F-15 and BOTSS play ok but they're shameless quarter suckers, regularly pestering the player to pump in more credits to buy weapons, repairs, fuel etc.
Tank Battle (aka Super Tank Attack and Tank 3D) is a prototype game. It supports two players via split-screen. I can't find a way to disable the split-screen for single player though.
BOTSS image 1 BOTSS image 2 BOTSS image 3 BOTSS image 4 BOTSS image 5 BOTSS image 6 BOTSS image 7 BOTSS image 8 BOTSS image 9
Tank Battle image 1 Tank Battle image 2 Tank Battle image 3 Tank Battle image 4 Tank Battle image 5 Tank Battle image 6 Tank Battle image 7 Tank Battle image 8
Buggy Boy as it was meant to be played. Three-screens of brightly-coloured fun. Not a great deal of difference hardware-wise to the upright version; same number of CPUs, just a little extra video RAM, more logic, PROMs etc. Desoldering three dozen ROMs/PROMs and PALs from a boardset in order to complete the emulation sure was fun...
The 1994 sequel to Sonic Blast Man, the infamous smack-the-punchbag-as-hard-as-humanly-possible game. Real Puncher featured a cabinet-mounted camera which enabled you to punch yourself or a friend in the face without consequence.
A British quiz game running on JPM System 5 with video expansion MK2 hardware. Answer questions correctly to buy properties, win cash or end up going round in circles because the game has decided it's not paying out. The actual machine has a monitor bezel resembling a Monopoly board which illuminates as you progress through the game. Without it, it's rather difficult to keep track of what's going on.
Also, there's Monopoly Classic (which is played for points only) and Monopoly Deluxe:
It's been a long time coming but finally we have some decent progress on this rare game.
Released in limited numbers in 1985, Turbo Sub was the second game developed by Entertainment Sciences for their Real-Time Image Processor (RIP) system (the first was 'Bouncer'). Based on a special video CPU with an AMD AM29116 core, the hardware allowed for a medium-res display with 4/8bpp, scalable sprites. Pretty impressive for the time! The game's sprites (like Bouncer) are from digitized cels and have a certain charm to them.
There's plenty of info on the game and the company at www.turbosub.com
The driver isn't quite ready for primetime yet. Once I fix sprite-scaling and coax speech out of the TMS5220 then we'll be good to go :)
(Minor Update: I corrected a daft mistake that was limiting the usefulness of the depth buffer causing some polygons to appear in the wrong order. I've updated the snaps)
The ratio of quiz games to real games has been a little high of late, so let's start to address the balance with something special...
Cube Quest is a 3D treasure hunt within the confines of a giant cube. Choose a path along the edges of the cube to reach the treasure star (you may rotate a face of the cube if it makes life easier) fighting through waves of enemies from dragonflies to biplanes along the way in gameplay similar to Gyruss.
Cube Quest is the second arcade game to feature solid-filled polygons (I believe it was released shortly after Atari's I-Robot). As you'd expect, the hardware is rather complex. An 8MHz 68000 commands three AMD AM2901 bit-slice ALU based processors. The first, a 16-bit 'Rotate' CPU, peforms 3D maths (including serial multiplication and division) much like the mathbox found in I-Robot, Battle Zone, Tempest etc. A 12-bit 'Line' CPU interprets the data sets produced by the Rotate CPU and produces series of line spans using a hardware implementation of Bresenham's line drawing algorithm, which are then processed by the line-fill circuit. Finally, there's a 16-bit CPU for 16-channel, stereo sound generation - not nearly as exciting as it sounds but it does produce some interesting sounds.
At present, there's an important aspect of the game absent from the emulation; the laserdisc-streamed backgrounds. There's 54 weird and wonderful tunnels to fly through, produced by animation pioneers Robert Abel and Associates (notable for The Jacksons, 'Can You Feel It' video). The game generates a 3D substitute background if the laserdisc player is absent or malfunctioning (see pic #4).
It's a very neat game which sadly did not enjoy commercial success back in 1983/1984. There's some laserdisc captures and pics of the cabinet at the following links:
http://www.dragons-lair-project.com/games/pages/cq.asp
http://home-and-garden.webshots.com/photo/1352844430054905596sgJcOL
http://www.dragons-lair-project.com/games/materials/audiovideo/audio/cube02.mp3 (Best intro narration ever :D)
BTW, thanks to Joe Magiera for dumping the several dozen PROMs and ROMS from his boardset.
A hybrid video/fruit machine running on Maygay MV1 hardware. Spin the reels, lose/win money and activate one of about a dozen video game sequences for the chance to win further prizes.
Hardware-wise, there's 68000 and 8032 CPUs, and for sound, a YM2413 and uPD7759 (there's sampled loops of Madness and 2 Unlimited :D). Graphics are handled by an Intel 82716; a sprite processor of sorts which allows for 16 arbitrarily sized sprites (subject to screen processing times).
This will be a perfect candidate for AGEMAME once artwork for the mechanical part is ready.
Another great game on JPM Impact hardware, with gameplay not entirely dissimilar to Hangman...
A couple of early British pub quiz games. These games load from a 3.5" double density disk! It's simple framebuffer video hardware based around a 68000 and a TMS34061 CRTC. The TMS serves as a handy DRAM controller; disk data is uploaded to the abundant supply of video DRAM and executed from there.
Now with accurate sprite-scaling and frame-buffer rotation. Rock-On!
This is another BFM Cobra disk-based game. It's based on an old BBC Radio 1 quiz. DLT FTW.
Thanks to Mqark for dumping it.
Invisible text is no longer. Turns out small fonts are written directly to the frame buffer by the Z80. At least they are when the bank selection works...
The game is playable up until the prize round, at which point the processors stop communicating. Swines.
I still haven't a clue how to fix the colours :/
The Quiz! The 'Vaders! The Graphics! Wow!
Thanks to Ken.e.B for obtaining a machine for dumping...
Another SWP game running on Bell-Fruit's Cobra system. This one stores most of its data on 3.5" disk. A bit more work is needed to fix the colours and invisible text.
A skill-with-prizes (SWP) game, frequently seen in British pubs a few years back. Runs on the JPM Impact with Video system (68000 + TMS34010). The inputs aren't hooked up and I can't explain the graphics corruption at the moment.
