0.62 [Phil Stroffolino]
0.55 [Phil Stroffolino]

NOTE:
- Starblade is available on the Playstation as Starblade Alpha, with the option to play in the original setting or an update with texture mapping on the polygons.

WIP:
- 0.133u1: hap properly added support for Namco System 2 multiple posirq anyway, this fixes Starblade large polygons displayed.
- 0.130u1: Changed description to 'Starblade (Japan)'.
- 0.120u1: Phil Stroffolino added gradient colors in Starblade and fixed crash in 2nd stage.
- 4th October 2007: Phil Stroffolino - One more mystery solved - background colors for Starblade's animated high score presentation are now correct - see the screenshot below. An updated MAME driver will be submitted soon.
- 0.119u1: Changed TMS32025 CPU6 clock speed to 96MHz. Added 2x c76.rom's to cpu5 and 6. Fixed rom names.
- 5th September 2007: Phil Stroffolino - I'm wrapping up what should be the last few bits of DSP Integration. A few open issues remain, but the final driver should be ready to publish by this weekend.
- 27th August 2007: Phil Stroffolino - Trojan for Namco System21 DSP BIOS is essentially complete, and ready to test on real hardware, but I ran into a wrinkle. The original intention was to extract the BIOS code, export it to shared RAM, then write it to EPROM, where it could be extracted using an off-the shelf EPROM reader. As it happens, the (Namco) EPROM handling currently implemented in MAME is not at all accurate to real hardware. It basically treats the address range for the EPROM as if it were normal RAM, and always reports "not busy" when EPROM state is queried. This is enough to satisfy the typical emulated game's use of EPROM for saved settings, etc. However, it would be very easy to write code that works in MAME, but fails completely on real hardware. When using real EPROM, busy states are important, you must take care to only write single bytes (not whole words), and you must take special care to "reinitialize" chunks of EPROM before storing replacement values there. Even more troublesome is that there physically isn't enough EPROM space on the System21 boardset to store the entire DSP BIOS. In any event, I will be further studying the ues of EPROM to improve emulation accuracy and better smoke-test the trojan. I will also be adding code to the trojan to display the BIOS contents onscreen in ascii using System21's sprite system as a backup plan. I don't want to waste anyone's time running trojans that are flawed, or my time rewriting experimental trojans.
- 24th August 2007: Phil Stroffolino - Something interesting about Starblade - the extra graphics aren't just decorative, as I'd thought. The big "static" objects that are now appearing can hide enemy starships and block your shots, explaining why the collision detection seemed kludgy when those large objects are invisible. The extra objects also often contain shootable "weak point" targets that can be blasted, explaining why shots into thin air sometimes caused a firey (sprite-based) explosion to appear. While the game is still at its heart a simple rails shooter, the extra graphics do make the game considerably more interesting. A small puzzle - occasionally, the DSPs draw quads "directly" to the screen, without using the 3D models encoded in the Point ROMs. This is usually done only for simple backdrop graphics, i.e. a series of quads to simulate a sky-box gradient. The color references for these quads, however, are a complete mystery. They don't appear to be pen references, as they are clearly wrong for all of the selectable color banks. I suspect a color-lookup table specific to "directly-drawn-quads" that is initialized on startup. In any event, all due (Sys21) focus is now on completing my trojan for the System21 DSP BIOS.
- 22nd August 2007: Phil Stroffolino - Starblade! As I'd suspected, the missing graphics had nothing to do with DSP emulation or use of a fake BIOS, but rather bugs in the 68k emulation - specifically subtleties with interrupt handling. I still have some tidying up before it's ready to submit. Moreover, I'd like to complete a proper trojan to extract the real BIOS code, which will allow a number of kludges and hacks to be removed from the driver.
- 21st August 2007: Phil Stroffolino - I finally found the missing graphics in MAME's emulation of Starblade. The master 68k sends object descriptions for all "dynamic" 3D objects directly to the DSPs for rendering - these are the graphics that are drawn correctly by MAME even now. Specifications for the remaining "static" 3D objects are written by the slave 68k cpu to a block of shareram that is normally used only for communication between the master and slave 68k. All the missing object descriptors are there, and it would be easy enough to hack the starblade driver to draw them, but it's not yet clear how they end up being transfered to the DSPs for rendering. Should be untangled soon.
- 20th August 2007: Phil Stroffolino - I've made decent progress with Namco System21 hardware, particularly with the older titles. Findings include: Winning Run is the original prototype hardware, with significant differences from newer hardware (Starblade, Cybersled). Winning Run uses a single DSP, and has (apparently) no internal BIOS. The master 68k uploads 100% of the DSP code at boot time. Winning Run doesn't use sprite hardware, but rather has an additional 68k processor whose sole function is to manage a 256 color bitmap layer. The most interesting discovery is use of Point RAM. A table of quad attributes is stored there, explicitly by the master 68k, that provide color and vertex indices relative to {x,y,z} coordinates in the Point ROMs. This same table is also used by the newer System21 games - games that were "mostly working" did so only because there similar information happens to be redundantly encoded in the Point ROMs themselves. winrun.zip is actually "Winning Run: Suzuka Grand Prix" Driver's Eyes runs on transitional hardware - it replaces the bitmap layer and GPU with the more modern sprite hardware, but still uses the older DSP configuration. The point ram control registers have been more fully documented. No progress yet with Stadblade's missing graphics, but I hope to untangle that soon.
- 0.118u2: Atari Ace fixed MACHINE_RESET in the Namco System 21 driver, this fixed MAME crashes when you reset
- 0.102: Aaron Giles fixed missing 3D graphics.
- 0.97u1: Phil Stroffolino updated the Namco System 21 driver. Starblade is working with emulated master/slave DSPs. Graphic updates are a bit choppy; I believe there are 4 slaves and one master on the real PCB, with work distributed across the slaves. Some background objects are still missing in Starblade - the giant "starships" in the background of the first stage, for example (sprites are present showing burning fires which are supposed to be superimposed on them). The "direct drawing" feature is used during the high score presentation; colors are likely wrong, and there are missing graphics there as well (hexagons).
- 0.86u3: Regression fixes and restored polygon drawing in Starblade [R. Belmont].
- 0.78u5: Phil Stroffolino hooked up the view transform, used in Starblade to tilt the screen when player is targeting the edges of the playfield.
- 0.62: Phil Stroffolino added Starblade (Namco 1991).
- 24th August 2002: Phil Stroffolino submitted the Namco System 21 and 22 drivers. Starblade and Solvalou are playable though missing some background graphics, the rest suffer from various problems.
- 23rd August 2002: Phil Stroffolino reported some progress with the Namco System 21 driver, which supports Starblade, Air Combat, Cyber Sled and Solvalou. All games have full sound support thanks to R. Belmont. Starblade is fully playable, but the other games are preliminary and suffer from various graphics glitches and lack of input ports.
- 0.55: Added Starblade (Testdriver). Known issues: Some corrupt point data.

LEVELS: 2

Other Emulators:
* Mjolnir

Romset: 9144 kb / 25 files / 2.99 zip