philwip.mameworld.infoPhilWIP

Phil Bennett’s MAME page. 8th September 2013 Tap a Tune 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. 31st August 2013 Midnight Landing 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). 12th January 2013 Turret Tower 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! 16th November 2012 Rise of the Robots (prototype) 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. 31st July 2010 The Last Starfighter and Air Race (prototypes) 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...