I got a really clean looking PCB recently for cheap (about 100 bucks), a phoenixed Shinobi System 16b PCB. The problem with this PCB was that the sounds and such play, but no video. This is very similar to the KI2 board symptoms I had a while ago.

Anyway, the first thing I take a look at is the sync line on the pin edge. In a 16b, that’s on the underside, 3rd pin from the left. This is a trace that runs along the very edge of the board, and as such, is prone to breakage if the edges of the board come into contact with anything sharp or rough. I’m not kidding, between the very edge of the pcb and this trace is like 1mm of space! Normally there’s a space between the edges and the outer most trace.

Following the trail, I came to a very sharp gauge in the board. There were a few gauges on the back, as well as some close touching bent pins, but nothing serious. This gouge, however, was enough to break the video sync line.

I stripped away both sides of the trace, fluxed and patched the middle to solve the problem.

KI HDD Update

I took a short look into the possibility of downgrading a KI2 board to play KI1.

First of all, taking a look into MAME and running with a watchpoint of 0x10000100 for 64 bytes (HDD address lines), I see that all the HDD specific code is executed after the program is loaded into memory from the loader (the blue filling up the screen is basically the program decompressing into memory).

This makes patching the rom a little more difficult, because we either have to unpack the stored program, patch it, and pack it back again to inject in the right disk block, or, create (or find) some empty space in the rom to store our memory patch instructions post load.

I performed another test on the HDD. Now, I found something interesting. When I load up the vanilla KI HDD with the KI1 AnyIDE bootrom, I get to the test screen with only one menu option “diagnostic test” and the KI logo flashing. This is normal and documented behavior. But, I took the first few blocks of the KI2 HDD and the rest of the blocks of the KI1 HDD to fill up the space. I was thinking mabe it was a header thing or something that it would check in the HDD and move on. But, this time I got the same test menu, but with all the options displayed instead, and a half flashing KI logo.

This test, signals to me that the IDE controller itself plays a role in deciphering the contents of the HDD stream when the bootrom issues IDE commands. Well actually, more specifically, the IDE controller allows bytes to be read assuming the checks pass in the bootrom. The game code itself does all the deciphering of the stream, as this is the reason why the game works in MAME without emulating the IDE controller in U96.

MAME uses its own generic IDE controller implementation that accepts the same ATA commands, and the KI driver just needs to signal to the bootrom the model metadata when it asks for it, as that’s a check in the game code that was patched in the anyIDE version. The “protection” in U96 basically is to respond with an ATA signal that states readiness when the correct sequence of bytes written to the IDE command buffer addresses are written. So there are some sequence of commands that are performed prior to being allowed to read the HDD from the bootrom. Or, that’s how I understand what’s going on here anyway using IDA.

Still, the HDD test tells me another promising vector may be to re compose the HDD data in the KI2 way for KI1. It might be that both altering the bootrom and HDD image may be necessary in the case of a KI2 board. I’m not clear on the connection between the U96 chip and the HDD stream as I haven’t dumped U96 on the KI2 board. My guess is both, or at the very least the HDD are required to be recomposed.

pram0d