Charles MacDonald's Home Page

News (6/18)

Comms Link USB Replacement

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:

For developing large programs, the transfer utility can load data from disk and transfer it over the Comms Link interface. This allows you to simulate a CD environment without burning discs for each test. I am working on a demonstration program to show how to use these features which should be finished shortly.

Old News (6/14)

Racin' Force

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.

Of particular interest are the sloped curves on the racetrack, and the tunnel which has both a floor and ceiling made out of voxels. The PSAC4 chip has a lot of different drawing settings which have to get figured out. I've documented the PSAC2 registers and will tackle the PSAC4 next.

Game Genie information

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

A useful property of both Game Genie devices is that you can replace the program ROM(s) with an EPROM emulator to run your own code, then relocate to RAM and enable the plugged-in cartridge to run experiments on the cartridge hardware.

Old News (6/1)

16-bit EPROM emulator

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:

At some point I was thinking of making adapter PCBs that would support 27C4096 and 27C400 type pinouts as I have a few boards with those chips instead of two 8-bit EPROMs in parallel. It's just a wiring difference but this would be a neater solution and simplify cable assembly.

VDP pin assignments

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

If anyone does something cool like sticking a RAMDAC chip on the color bus outputs, do let me know. :)

V25 research

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]
It seems less important to have DS and ES register loads delay interrupts as well, I did not expect this behavior.

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)

Fresh start

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.

Knuckle Bash

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. :)


www.digits.com www.digits.com