Shinobi System 16B Fix Log

Following my painful success fixing a TMNT PCB, I decided to move on and try another.

I bought an untested (tm) Shinobi PCB from ebay as I like the game.

The PCB was in a dusty state, but was complete.

Of course, the board didn't really work. Although I was pleased to see it booted and did something!

The most noticeable problems:

1/ The graphics either had jailbars or were completely missing

2/ There was no sound. 

The game was actually playable under all those jailbars.

The first thing I did was to remove Sega's FD1094 processor and replace it with a stock Motorola 68000. I reprogrammed the relevant EPROMs. There are also some reports that these boardsets exhibit unpredictable behaviour, including the sound failing, when the battery is on the way out. This didn't fix any of the issues, but gave me the comfort in knowing the board wouldn't die in the future when the ageing processor battery expired.

Graphics

The test mode showed one of the RAMs was bad.

This is the RAM shown below.

I bought a spare from China, and socketed it. Desoldering went a little smoother than the TMNT desoldering marathon, but I still had to snip the legs of the old chip and spend maybe an hour or two on the chip. The end result was pretty clean, so at least my desoldering is improving. I can't say this is a particularly enjoyable part of the hobby for me. 

Unfortunately, this didn't fix the bulk of the issues.

On a positive, the RAM test now passed, and the graphical problems seemed marginally better with less random garbage on-screen. The jailbars remained though. 

At this point, I could tell that it was just the tile graphics that had problems. The sprites seemed fine. I did some highly technical 'pressing on EPROMS' and noticed I could reduce the width of the jailbars with some pressure.

I removed the tile EPROMs and checked them in my reader. One of them was full of junk data and didn't match the expected CRC.

I programmed a new EPROM and the graphics were restored and the game looked perfect. 

Unfortunately, after running the game for about 30 minutes the sprites also developed a problem with lines running through them.

In hindsight, maybe this problem was intermittent as the sprites were also screwed in my original screenshot of the game. 

I used my System 16 Sprite Viewer to determine where the garbled graphics were located. Once again, I found a faulty EPROM and reprogrammed it.

Graphically everything is working again! Phew!

Sound

- I verified the 3 sound EPROMs were good. After all the previous EPROM failures, they were the first thing I suspected. 

- I checked the Z80 isn't in a HALT / RESET state. It seemed to be running. 

- I could  hear hum from the amp when the pot is turned up. Tapping the logic probe on the outputs of the YM3012 causes audio interference.The amplification part of the circuit is working. However, data wasn't being fed into this chip correctly. So something was going wrong upstream. 

- I tried piggybacking the SRAM used by the sound processor. This didn't change anything.

Using a logic probe, I spotted some bad activity at the YM2151 sound chip The following pins were suspect:

21  Serial Output      

Stuck Low [Connected to DATA on YM3012, should be doing something]

20  Sample & Hold 1    

Stuck High [Connected to SAM1 on YM3012, should be doing something]

19  Sample & Hold 2    

Stuck High [Connected to SAM2 on YM3012, should be doing something]

There was sensible looking activity on the data and A0 pins. Downstream, the YM3012 wasn't doing anything sensible. The analog and channel outs were floating. 

I didn't know which of the two components was faulty, so I ordered both. The output from the YM2151 was clearly borked whereas the inputs seemed sensible. I wasn't entirely sure whether a damaged YM3012 could also be causing this. 

I socketed and replaced the YM3012 first, mainly because it had fewer pins to desolder!

This didn't fix the problem, so I socketed and replaced the YM2151.

This fully restored the audio.

In summary, I replaced:

Desuicide

1 x 68K Processor

2 x EPROMs

Fix Graphics Problems

2 x EPROMs

1 x SRAM

Fix Sound

1 x YM2151

1 x YM3012 (Unnecessary)

CannonBall SDL 2 Code Changes

I haven't done any coding work on CannonBall lately. This isn't because the project is abandoned, or that I've lost interest as I still have plenty of ideas. It's simply a result of my limited amount of time and as such I've focused my attention elsewhere.

Having said that, Manuel Alfayate has made some critical backend changes which result in CannonBall performing really well on Linux based systems including the Raspberry Pi. Previously performance was stuck in low gear.

Firstly, he has ported CannonBall to SDL 2. The codebase previously used the ancient SDL 1.2 library. This results in accelerated, fullscreen, X-less mode for the Pi using SDL 2. To utilise this, you must build the sdl2 or sdl2gles cmake profiles.

Right now, SDL 1 is still included in the codebase and is the default for Windows, but it will be phased out the next time I release a new version. Right now , the main benefits will be for Linux based systems where you don't want to rely on an X-Windows GUI environment.

There is still optimization needed for the Pi 1 and Pi Zero. I'd like to look into this when I have some time. But once you're past the sluggish start line, you can achieve 60fps in widescreen mode. Not bad for a $5 machine.

Here's a video of the changes in action with the frame counter on display. A $5 OutRun PCB could closer than you might think...

I've merged his changes into the main codebase. 

Konami Teenage Mutant Ninja Turtles PCB Fix

I recently extracted all my PCBs from my parent's garage. These had been sat in cold conditions since the 1990s and not used in years.

Surprisingly, everything I tested worked. Apart from my Konami TMNT which had corruption to the graphics. The sprites rendered fine in isolation, but the tiled graphics clearly had major problems.



The game ran fine.
The sound plays.
The RAM/ROM check passed.
The Mask ROM check failed. This required setting a DIP switch to test.

Unfortunately, the Mask ROM test screen was so garbled it was unreadable and I inferred the wrong Mask ROM was bad! In the end, I swapped out two ROMs rather than one. For reference the screen looks like this (not my picture!)



After desoldering the Mask ROMs, I used 27c400 EPROMs as replacements.



And everything now works. Turtle Power!