News (6/18)

I had worked on a Comms Link compatible device in 2007 to allow development of Sega Saturn software without having to use an old ISA-equipped computer. It had some timing issues that I wasn't able to diagnose at the time. I decided to revisit the project and dumped the PALCE20V8H chip from a clone Comms Link ISA card to see how the communication logic was implemented. Turns out one of the strobe signals need to be active high instead of active low, something that was fixed with a minor tweak to the GAL equations. Now that it works as expected, I've decided to clean up the project and release it. Here is the PCB layout, GAL equations, and source code:

• ar-061808.zip

Old News (6/14)

I've been running some tests on Racin' Force, a Konami System GX game that uses voxels to generate a 3D playfield. It's an interesting combination of new and old hardware, the PSAC2 chip from earlier games generates a 2D ROZ layer which selects data from a color map and height map. This is used by the PSAC4 chip to render voxels to a framebuffer. An additional list of per-scanline camera data is provided as the PSAC4 knows nothing about the rotation parameters the PSAC2 applied to the color map and height map. Priority is specified for each voxel drawn so sprites can move in front of and behind specific parts of the landscape.

A limitation of this setup is that dropped pixels in the PSAC2 output result in missing voxel columns which makes landscape structures look flickery. However at 60 frames per second the results are extremely impressive. Consider how few custom ICs were needed to do this compared to the 3D hardware some arcade games used in 1993. For games with simple terrain such as Racin' Force and Konami's Open Golf Championship, the decision to use voxel graphics was well suited to their graphical needs and a cost-effective choice.

I made a low-quality video of the game in action. No controls are wired up, so the car is out of control after the attract sequence.

• Racin' Force footage

Here is a description of the Genesis and SNES Game Genie, and a description of the SGA001 ASIC that Codemasters designed:

• genie.txt

Old News (6/1)

Last year I designed a 16-bit EPROM emulator based around the IDT7025 8Kx16 dual-port static RAM, a very useful chip that supports 8 and 16-bit access independently on either of its RAM ports. This is what I used for running tests on my Model 1 and Jaleco Mega System 32 boards, the latter needing two emulators in parallel to emulate four EPROMs.

The software to control it was a modified version of the 8-bit EPROM emulator utility. Support for multiple devices isn't implemented quite right, so just use it for controlling a single device. This ended up being my first project that used almost all surface mount parts, as well as PLCC chips. I'm quite proud of the way it came out, and so far it has been invaluable for running tests on 16-bit and 32-bit systems. Here is the PCB layout, documentation, utility program and source code:

• ds-060108.zip

Here is a mostly complete pinout for the 315-5313 VDP.

• vdppin.txt

There are a number of instructions which delay interrupt and exception processing, allowing one more instruction to be executed before the interrupt is taken:

    POPF, CLI, STI
    POP [segment-register]
    MOV [segment-register], r/m16
    Segment prefixes: CS, DS, ES, SS
    Repeat prefixes: REP, REPNE, REPC, REPNC
    LOCK prefix

For the prefixes, this prevents an interrupt from being taken after the prefix byte has been fetched but before the instruction it applies to has been executed. Likewise for segment register loads, if an interrupt occurred after SS was changed, SP would be invalid. By delaying interrupts the following types of sequences become uninterruptible:

    pop ss
    mov sp, $F800
    ; or
    mov ss, [si+0]
    mov sp, [si+2]

I have been looking at the MCU code for other games and it seems that they use similar, if not identical instruction encodings, despite using differently labeled MCUs. V-Five in particular seems to match the Knuckle Bash opcodes quite closely, and when/if I can get Knuckle Bash decrypted, I'll see how much of V-Five can be decrypted.

Old News (4/12)

Getting the website fixed up, most links will not work. There was an exploit in the blog script that was being taken advantage of, so I'm going back to basics. I'll see what I can do about getting the old blog content back here.

I recently acquired a Toaplan "Knuckle Bash" PCB. It's a fairly impressive system, based around a custom graphics chip which displays three tiled background layers and two 512x512 12-bit framebuffers for double buffered sprites. It has a 68HC000 running at 16 MHz that handles all the game related tasks, and a V25S MCU that manages inputs, sound effects, and music playback. The music for this game is quite good and definitely a notch above the rest. A lot of other Toaplan games use the same graphics chip, so I'm intending to run tests on it and get all the timing and other details worked out.

The V25S microcontroller is a 80186 clone manufactured by NEC. Unlike the V25 it has no usable internal ROM and no 8080 emulation mode, the latter of which has been modified to add a new 'secure' operating mode. In secure mode a lookup table translates opcodes fetched from memory with their V25S equivalents. This allows the opcode-to-instruction mapping to be changed as the customer (Toaplan) sees fit, making the program code unusable unless the table contents are known. Luckily operands and data are not encrypted, and examination of the operands such as the ModR/M byte can reveal what category of instructions a particular opcode might fit in to.

NEC intended for the V25S to be used as a drop-in replacement for the V25, to accomplish this it uses one of the unused V25 pins as a mode select input. When tied high or floating (due to an internal pull-up resistor) the CPU runs in normal mode, where the lookup table is bypassed and opcodes are processed normally. When tied low, the CPU is in secure mode and the lookup table is utilized. This pin is sampled during a reset, interrupt, or exception, and bit 15 of the PSW can be modified through select instructions to change the operating mode regardless of the pin state as well. These features allow a V25S to start in normal mode and selectively execute encrypted programs while still interacting with a unencrypted BIOS, operating system, and device drivers, or vice-versa.

I modified the Knuckle Bash board to start the V25S in normal mode, and developed a program that sets the MCU to a known state and enters secure mode with the instruction trap feature enabled. This forces just one encrypted instruction to be executed before control is passed back to my unencrypted code, at which point the potentially modified state of the MCU is saved and examined. The behavior of all encrypted opcodes (except BRKS which sets up an unrecoverable state) can therefore be examined. I can see things like what data was pushed or popped from the stack, which registers were loaded, exchanged, or modified, and which instructions triggered an I/O or floating point exception. A lot of information can be gathered about the encrypted instructions, which narrows down or completely identifies which unencrypted instructions they map to. Best of all this technique should work for any V25S based system, such as the other Toaplan games. I'm looking forward to trying it on my Golden Axe 2 security board to see how effective it is after finishing with Knuckle Bash, though right now it's too early to give any indication of progress.

Toaplan did an excellent job with the protection. The program ROM is filled with valid Z80 code and garbage data to throw off statistical analysis of the ROM, such as observing the frequency of occurance for particular bytes and byte sequences. The MCU has no manufacturer marking and has ambiguous names printed on it like "NITRO" and "DASH". Furthermore, the lookup table maps many opcodes to the same instructions so certain easily identifiable instructions can simply never be executed, increasing the number of potential matches any encrypted instruction might have. If this technique is applicable to the V35S, we'll have to see what Irem did with their games. :)